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EXBCDTIVB  80MKXRY 


The  overall  objective  of  the  Departoent  of  Defense  Coaputer-a idea 
Acquisition  and  Logistic  Support  (CALS)  Program  is  to  integrate  the 
design,  manufacturing,  and  logistic  functions  through  the  efficient 
application  of  computer  technology.  NIST  has  been  funded  since 
Spring  1986  to  recommend  a  suite  of  industry  standards  for  systeja 
integration  and  digital  data  transfer,  and  to  accelerate  their 
implementation. 

During  FY86  NIST  tasks  for  CALS  in  the  area  of  graphics  standards 
focused  on  identification  of  recommended  standards  to  OSD  which 
would  be  applicable  to  the  DoD  environment;  comparison  of  graphics 
standards  among  themselves  and  with  product  data  standards;  and  the 
status  of  ongoing  graphics  standards  efforts  as  well  as  related 
validation  efforts  .  CALS'  needs  for  graphics  standards  were 
assessed,  and  an  architecture  for  their  inclusion  into  specific 
CALS  programs  was  created.  Finally,  a  plan  was  recommended  for 
accelerating  the  development,  related  validation  efforts  and 
implementation  of  graphics  standards  into  the  CALS  program. 

Building  on  the  knowledge  and  experience  gained  during  FY86,  NIST 
tasks  for  CALS  in  the  area  of  graphics  standards  in  FY87  emphasized 
the  particular  graphics  standard  dealing  with  the  transfer  of 
pictorial  data  from  one  system  to  another,  namely  the  Computer 
Graphics  Metafile  (CGM)  standard  (FIPS  PUB  128)^.  Graphics  tasks 
included  an  assessment  of  raster-to-vector  conversion  technology, 
and  where  the  CGM  might  fit  into  that  process;  efforts  toward 
development  of  CGM  validation  routines;  injection  of  CALS 
requirements  into  the  Extended  CGM  (CGEM)  standards  work,  as  well 
as  into  the  CGM  Registration  process.  In  addition,  functional 
requirements  and  conceptual  design  documents  were  completed  for  a 
reference  implementation  for  CGM;  a  design  specification  was 
created  for  an  IGES-to-CGM  translator;  and  a  preliminary  CALS 
Application  Profile  for  CGM  was  formed  from  the  application  profile 
work  of  the  MAP/TOP  organization. 

During  FY88,  NIST  tasks  for  CALS  in  the  graphics  standards  area 
were  in  large  measure  a  continuation  of  those  efforts  begun  the 


’Kemmerer,  S.,  Editor,  "Final  NBS  Report  for  CALS,  FY86,"  U.S. 
Department  of  Commerce,  National  Bureau  of  Standards,  NBSIR  87- 
3566,  May  1987. 

^Kemmerer,  S.,  Editor,  "A  Collection  of  Technical  Studies 
Completed  for  the  Computer-aided  Acquisition  and  Logistic  Support 
(CALS)  Program,  Fiscal  Year  1987,"  U.S.  Department  of  Commerce, 
National  Bureau  of  Standards,  NBSIR  88-3727,  March  1988. 
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year  before^.  Final  text  was  completed  for  the  initial  publication 
of  a  Military  Specification  which  is  the  CALS  Application  Profile 
for  CGM.  NIST  continued  to  participate  in  graphics  standards  work 
in  support  of  CALS  requirements  in  the  areas  of  CGM  conformance 
testing,  the  CGEM,  and  CGM  Registration.  In  the  particular  area 
of  CGM  conformance  testing,  the  needs  for  testing  both  to  FIPS  128 
and  to  the  Application  Profile  for  CGM  were  identified;  existing 
commercial  implementations  of  CGM  were  analyzed  and  compared 
functionally  to  both  CGM  and  Application  Profile  requirements;  and 
required  CGM  conformance  testing  tasks  were  described  in  detail, 
responsibilities  in  the  testing  process  delineated,  and  the  impact 
of  CGM  testing  was  assessed  both  for  CALS  and  the  commercial 
marketplace . 

This  collection  of  reports  represents  the  continuing  efforts  of 
the  Graphics  Software  Group  of  NIST/NCSL  in  FY89  in  support  of 
computer  graphics  standards  for  CALS,  and  in  particular  CGM*'.  It 
provides  a  progress  report  on  continuing  graphics  standards  efforts 
related  to  the  Computer  Graphics  Metafile  (CGM)  standard,  including 
the  Extended  CGM  (CGEM) ,  Graphics  Registration,  and  the  CGM 
Application  Profile  for  CALS  (or  MIL-D-28003 ) .  In  addition,  the 
creation  of  a  Test  Requirements  Document  for  MIL-D-28003  is 
detailed.  This  Test  Requirements  Document  will  provide  the  basis 
for  developing  conformance  tests  to  determine  compliance  with  MIL- 
D-28003  . 

This  report  is  subdivided  into  four  separate  final  CALS 
deliverables,  entitled  as  follows: 

1.  Test  Requirements  Document  for  CALS  CGM  Conforming  Basic 
Metafiles 

2.  Injection  of  CALS  Recfuirements  in  the  Extended  CGM  (CGEM) 
Standards  Work 

3.  MIL-D-28003  Revision  Recommendations 

4.  CGM  Registration  in  Support  of  CALS  Requirements 


^Morgan,  Roy  S.,  Editor,  "A  Collection  of  Technical  Studies 
Completed  for  the  Computer-aided  Acquisition  and  Logistic  Support 
(CALS)  Program,  Fiscal  Year  1988,  U.S.  Department  of  Commerce, 
National  Institute  of  Standards  and  Technology,  NISTIR  4315,  4316, 
and  4317. 

^The  publishing  of  this  collection  of  reports  does  not  imply 
that  the  CALS  Office  has  endorsed  the  conclusions  or 
recommendations  presented. 
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An  additional  deliverable  completed  for  CALS  by  the  Graphics 
Software  Group  during  FY89  detailed  the  impact  that  two  other 
graphics  standards  (namely  PHIGS,  or  the  Programmers  Hierarchical 
Interactive  Graphics  System,  and  PIK,  or  the  Programming  Imaging 
Kernel)’  will  have  on  the  CALS  environment.  It  was  published  under 
separate  cover,  and  is  available  through  the  CALS  Policy  Office  or 
through  the  National  Technical  Information  Service. 


^Kemmerer,  Sharon  J.,  and  Skall,  Mark  W. ,  "Graphics 
Application  Programmer's  Interface  Standards  and  CALS,"  U.S. 
Department  of  Commerce,  National  Institute  of  Standards  and 
Technology,  NISTIR  89-4199,  October  1989. 
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ABSTRACT 

The  purpose  of  this  report  is  to  satisfy  the  requirements  of  CALS 
FY89  Statement  of  Work  Task  4.1.1,  which  states: 

Continue  to  accelerate  the  development  of  CGM  validation 

routines  and  ensure  the  input  of  CALS  requirements. 

In  previous  related  tasks,  NIST/NCSL  has:  developed  a  plan  for  the 
development  of  conformance  tests  for  both  FIPS  PUB  128  (CGM)  and 
MIL-D-28003;  compared  the  variability  of  commercial  CGM  generator 
implementations  and  how  well  they  conform  to  MIL-D-28003;  and 
assessed  the  impact  of  CGM  test  development  strategy  with  respect 
to  the  CALS  environment  and  the  marketplace.  Finally,  as  part  of 
last  fiscal  year's  work  on  CALS,  NIST/NCSL  prepared  a  comprehensive 
list  of  tasks  that  must  be  accomplished  in  order  to  put  into  place 
a  testing  service  for  both  FIPS  PUB  128  and  MIL-D-28003.  This 
report  is  a  follow-on  to  that  work,  and  fulfills  one  of  the  most 
important  tasks  identified  concerning  the  development  of  a  Test 
Method,  i.e.  to  create  a  Test  Recjuirements  Document. 
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I.  OVERVIEW  AND  METHODOLXXJY 

A.  Overview 

The  Computer  Graphics  Metafile  (CGM)  standard  (ISO  8632; 
ANSI/X3.122;  FIPS  128)  is  a  data  transfer  standard.  In 
particular,  it  specifies  the  content  of  a  logical  file  to  be  used 
in  storing  and  interchanging  picture  descriptions  ainc<g 
applications.  Conformance  statements  in  the  CGM  standard  appxy 
to  instances  of  CGMs  and  not  to  generators  (writers)  of  CGMs  nor 
to  interpreters  (readers)  of  CGMs.  Consequently,  the  standard 
specifies  mainly  syntactic  recjuirements ;  there  are  very  few 
semantic  requirements  to  be  met  by  a  conforming  instance  of  a 
CGM. 


B.  Purpose 

The  purpose  of  a  Test  Requirements  document  is  to  gather  together 
all  requirements  that  must  be  satisfied  in  order  for  a  given 
instance  of  an  implementation  of  a  graphics  standard  to  be  in 
confoirmance  with  that  standard.  In  the  case  of  the  CGM  standard, 
an  instance  of  a  CGM  whose  conformance  is  in  question  will  be 
called  a  CGM-under-test . 

C .  Scope 

This  test  requirements  document  is  meant  to  apply  to  CGMs  that 
attempt  to  comply  with  MIL-D-28003,  the  CALS  Application  Profile 
for  the  CGM.  Consequently,  the  document  has  gathered  only  those 
requirements  that  apply  to  Binary  Encoded  CGMs;  i.e.,  those  that 
conform  to  Parts  1  and  3  of  the  CGM  standard. 

D.  Use 

This  document  is  intended  for  use  by  (1)  programmers  who  must 
build  a  testing  tool  capable  of  determining  whether  a  given 
instance  of  a  CGM  is  in  conformance  with  MIL-D-28003  and  (2) 
buyers  who  need  to  judge,  by  whatever  means  are  available, 
whether  a  given  CGM  is  in  conformance  with  MIL-D-28003.  In 
addition,  programmers  responsible  for  producing  products  with 
capabilities  for  CGM  generation  or  interpretation  will  find  this 
document  valuable 

Although  specifically  targeted  at  CALS-conforming  CGMs,  the 
document  presents  the  CALS-sp  cific  requirements  of  MIL-D-28003 
separately,  so  that  the  documen,  is  of  value  to  anyone  needing  to 
test  Binary  Encoded  CGMs  for  conformance  to  the  CGM  standard.  In 
addition,  because  the  Functional  Requirements  are  documented 
separately  from  the  Encoding  Requirements,  this  document  could 
also  serve  as  the  basis  for  a  more  comprehensive  CGM  Test 
Requirements  document  that  deals  with  all  three  standardized 
encodings  of  the  CGM. 
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E.  Methodology 


The  CGM  Functional  Description,  ISO  8632-1:1987,  was 
systematically  read  and  all  requirements  relating  to  the 
conformance  of  instances  of  CGMs  were  extracted.  Section  III 
presents  the  results  of  that  analysis.  A  similar  approach  was 
taken  for  the  CGM  Binary  Encoding,  ISO  8632-3:1987,  and  the  CALS 
Application  Profile,  MIL-D-28003.  The  results  are  summarized  in 
Sections  IV  and  V,  respectively.  In  these  sections,  like 
requirements  are  grouped.  [NOTE:  Because  this  document  is 
intended  to  be  used  in  the  development  of  an  international  CGM 
conformance  testing  tool,  the  requirements  were  derived  from  ISO 
8632:1987,  It  should  be  further  noted  that  ISO  8632  and  ANSI 
X3,122  are  identical  except  for  document  layout  and  style  (i.e., 
page  numbers  may  differ) . ] 

From  the  total  set  of  requirements,  three  major  summary  tables 
were  assembled  and  : re  presented  as  Appendices.  First,  Appendix 
A  contains  the  description  of  a  finite  state  machine  that 
enforces  exactly  all  CGM  Element  ordering  requirements  contained 
in  the  standard.  Next,  Appendix  B  contains,  in  tabular  form,  the 
parameter  list  lengths  for  all  elements  in  a  CALS-conforming  CGM. 
Finally,  Appendix  C  presents  a  matrix  stating  the  requirements 
that  must  be  met  by  each  parameter  of  each  CGM  Element  appearing 
in  a  CALS-conforming  CGM, 

These  tables  summarize  and  account  for  over  two-thirds  of  the 
specific  requirements  statements  found  in  the  CGM  standard.  The 
conformance  implications  of  the  remaining  requirements  statements 
cannot  fruitfully  be  characterized  in  a  simple  table.  Instead, 
an  expository  technique  has  been  chosen,  which  is  elaborated  in 
Section  II,  based  on  describing  the  be'"  ivior  of  a  hypothetical 
"black  box,"  whose  task  it  is  to  determine  whether  a  given  CGM- 
under-test  is  in  conformance  with  MIL-D-28003. 

The  black  box  is  called  a  "CGM  Parser/Verifier."  Its  operation 
is  broken  down  into  six  major  steps,  which  can  be  thought  of  as 
relatively  autonomous  program  modules,  plus  a  reporting  step. 
Section  II  gives  a  complete  description  of  the  behavior  of  the 
parser/verifier  and  assumes  that  the  parser/verifier  uses  the 
information  embodied  in  the  summary  tables  of  Appendices  A,  B, 
and  C. 

To  complete  the  report.  Section  VI  gives  a  cross  reference 
between  each  raw  requirement  statement  and  the  Table  (Appendix  A, 
B,  or  C)  or  Step  (in  Section  II)  where  the  tesr  requirement  is 
represented  for  testing. 
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II.  REFERENCE  ARCHITECTURE  FOR  A  CGM  PARSER/ VERIFIER 

A.  Overview 

The  CGM  standard,  ISO  8632:1987,  Parts  1  (Functional  Description) 
and  3  (Binary  Encoding) ,  specifies  the  content  and  structure  of  a 
conforming  metafile.  This  section  describes  the  high-level 
design  of  a  CGM  parser/verifier  whose  objective  is  to  determine 
whether  a  given  CGM  is  conforming.  If  the  CGM-under-test  is 
conforming,  the  parser/verifier  should  produce  a  conformance 
report  stating  this  fact.  If  the  CGM-under-test  does  not  conform 
to  the  standard,  the  conformance  report  should  include  a 
description  of  each  conformance  violation  discovered  including 
its  location  (as  a  logical  octet  offset  from  the  start  of  the 
CGM)  . 

MIL-D-28003,  "Digital  Representation  for  Communication  of 
Illustration  Data:  CGM  Application  Profile,"  places  additional 
constraints  on  the  structure  and  content  of  a  CALS  basic 
conforming  metafile.  In  the  following  description  of  the 
parser/verifier  operation,  CALS-specif ic  tests  are  separated  into 
their  own  paragraphs  and  preceded  with  the  phrase  "CALS". 

B.  Parser/Verifier  Operation 

The  parser/verifier  is  divided  into  a  number  of  relatively 
autonomous  modules  described  in  the  sections  that  follow. 

1.  Step  1;  Physical  to  Logical  Mapping 

The  CGM-under-test  is  opened  and  the  initial  information  is  read 
from  the  file  into  an  internal  buffer.  Because  the  CGM  is 
logically  viewed  as  a  continuous  stream  of  bits,  organized  as 
octets  and  words,  according  to  specific  definitions  in  the 
standard,  it  is  in  this  module  that  all  operating-system  and 
programming-language-specific  matters  like  byte  swapping  and 
fixed-length  and  variable-length  record  structures  are  dealt 
with.  For  the  rest  of  this  discussion,  it  is  assumed  that  all 
subsequent  steps  are  able  to  get  any  number  of  octets  from  the 
logical  CGM-under-test  in  the  correct  order  without  worrying 
about  whether  there  are  file  markers,  record  markers,  and  the 
like  embedded  in  the  stream  of  octets  returned  to  the  lexical 
phase  (step  2) . 

CALS.  MIL-D-28003  specifies  that  basic  conforming  metafiles 
consist  of  80-octet  fixed-length  records.  If  transmitted  on 
magnetic  tape  in  accordance  with  MIL-STD  1840A,  they  are  blocked 
into  800-octet  physical  records  (i.e.,  10  records  per  block). 
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2  •  Step  2:  Lexical  Phase 


Two  octets  are  obtained  from  the  CGM-under-test .  They  represent 
the  command  header  (short  form) .  The  element  class  and  id  are 
extracted  and  saved.  The  length  is  examined  to  determine  if  a 
long-form  element  is  present.  If  so,  another  two  octets  are 
obtained.  The  parameter  length  information  (short  or  long)  is 
saved.  Bit  15  is  examined  in  the  long  form  to  determine  whether 
data  partitioning  is  in  effect.  The  starting  point  of  the  next 
command  header  (or  next  data  partition)  is  calculated,  taking 
into  consideration  that  command  headers  and  partitions  start  on 
word  boundaries. 

One  special  piece  of  processing  that  can  occur  here  is  detecting 
when  all  the  elements  comprising  the  parameter  data  in  a  METAFILE 
DEFAULTS  REPLACEMENT  element  have  been  picked  up.  Prior  to 
getting  the  command  header  of  the  first  element  following  the 
METAFILE  DEFAULTS  REPLACEMENT  element,  the  state  should  be  set  to 
MDOP. 


CALS.  In  a  basic  conforming  metafile,  the  METAFILE  DEFAULTS 
REPLACEMENT  element  shall  not  be  partitioned.  If  partitioning  is 
encountered,  generate  an  appropriate  CALS-conf ormance  violation 
message,  write  it  to  the  profile  error  report  file,  and  increment 
the  count  of  such  errors. 

3 .  Step  3;  Element  Recognition 

If  the  class/id  is  recognized  as  one  of  the  valid  opcodes,  a 
frequency  count  for  each  opcode  encountered  is  incremented. 
Then,  processing  masses  to  Step  4  (Element  Processing) . 

Otherwise,  a  conformance  violation  message  is  formulated  and 
output  to  an  error  report  file,  and  the  error  count  for  this 
category  of  error  is  incremented.  Then  the  octet  pointer  into 
the  CGM-under-test  is  positioned  to  the  start  of  the  next  command 
header,  skipping  past  all  parameter  data  for  the  illegal  element, 
including  any  data  partitions  that  might  be  encountered.  Control 
is  returned  to  step  2. 

4  •  Step  4;  Element  Processing 

If  this  element  is  the  first  element  in  the  metafile  and  it  is 
not  the  BEGIN  METAFILE  element,  the  parser/verifier  immediately 
halts  processing  with  an  appropriate  message. 

Each  valid  CGM  element  needs  its  own  processing  section,  because 
different  specific  actions  need  to  be  taken  for  each  element. 
However,  the  processing  follows  a  familiar  pattern,  which  is 
described  in  the  following  paragraphs. 
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It  is  assumed  that  the  parser/verifier  has  established  a  set  of 
global  variables  which  contain  both  the  current  metafile  default 
values  for  all  Metafile  Descriptor,  Picture  Descriptor,  Control, 
and  Attribute  elements  and  the  current  parser/verifier  values  for 
all  Picture  Descriptor,  Control,  and  Attribute  elements.  It  is 
also  assumed  that  the  parser/verifier  is  checking  element 
ordering  rules  by  implementing  the  finite-state  machine  logic 
according  to  the  description  provided  in  Appendix  A. 

(Step  4A:  Check  Element  Order)  First,  the  current  state  of  the 
parser/verif ier  is  compared  against  the  states  allowed  for  this 
element.  If  the  element  is  not  allowed  in  this  state,  an 
appropriate  error  message  is  formulated  and  written  and  the  error 
count  updated  for  this  class  of  error.  However,  processing  is 
allowed  to  continue. 

CALS.  MIL-D-28003  places  some  constraints  on  the  use  of  ESCAPE 
elements,  and  GDP  elements  are  not  permitted.  These  constraints 
are  shown  in  the  state  table  summary  section  (Appendix  A) . 

(Step  4B:  Acquire  Parameter)  The  correct  number  of  octets  for 
each  parameter  is  picked  up  in  turn  from  the  CGM-under-test . 
This  number  often  varies  according  to  the  current  variable 
settings.  If  the  number  of  octets  needed  would  exceed  the  number 
of  octets  remaining  available  for  this  element,  processing  of 
this  element  is  aborted  and  control  passes  to  Step  2,  after  an 
appropriate  error  message  is  formulated  and  written  and  the  error 
count  updated  for  this  class  of  error.  During  this  step,  one 
must  be  careful  to  observe  rules  relating  to  byte  and  word 
alignment,  where  they  apply  (e.g,  in  the  CELL  ARRAY  element) — 
see  Section  IV,  requirements  B2 ,  B13,  B14,  B15,  B18,  B19,  B32, 
and  B33. 

CALS.  MIL-D-28003  restricts  the  range  of  allowed  precisions  to  a 
subset  of  all  those  allowed  by  the  CGM  standard.  The  length  (in 
octets)  of  each  element  in  a  basic  conforming  metafile  is  shown 
in  a  summary  table  (Appendix  B) .  All  valid  element  lengths  are 
shown  where  the  basic  set  permits  more  than  one  precision. 

(Step  4C:  Decode  Parameter)  The  parameter  is  decoded  according 
to  the  data  type  expected  for  this  element.  If  any  error  occurs 
upon  decoding,  an  appropriate  error  message  is  formulated  and 
written  and  the  error  count  updated  for  this  class  of  error. 
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(Step  4D:  Check  Parameter  Range)  The  parameter  is  then  checked 
against  any  range  constraints  that  might  apply.  These 

constraints  might  be  universal  (e.g.,  an  enumerated  type  must  be 
either  0  or  1)  or  might  be  dependent  upon  the  current  variable 
settings  (e.g.,  all  colour  indices  roust  be  non-  negative  and  no 
greater  than  the  maximum  colour  index) .  If  any  parameter  fails  a 
range  check,  an  appropriate  error  message  is  formulated  and 
written  and  the  error  count  updated  for  this  class  of  error. 
Range  checks  for  strings  include  verifying  that  the  string  length 
is  non-negative  and  that  the  strings  contain  only  legal  character 
codes.  This  latter  check  may  depend  upon  the  value  of  the 
Character  Coding  Announcer. 

CALS.  MIL-D-28003  permits  only  a  subset  of  the  permissible  CGM 
values  for  each  parameter  to  be  present  in  a  basic  conforming 
metafile.  Appendix  C  shows  the  allowable  range  for  each 
parameter  and  is  annotated  with  these  additional  CALS-  specific 
range  constraints,  when  the  CALS  Basic  Set  is  a  proper  subset  of 
the  permissible  CGM  values  according  to  the  CGM  standard. 

(Step  4E:  Perfoirm  Element-specific  Special  Processing)  Once  all 
the  parameters  for  an  element  have  been  acquired,  any  special 
processing  for  that  element  can  take  place.  Special  processing 
for  each  element  or  group  of  elements  is  described  in  Step  5. 

5.  Step  5!  Special  Element  Processing 

BEGIN  METAFILE:  Set  all  current  metafile  defaults  to  the  fixed 
defaults  specified  in  the  standard.  Save  the  string  parameter 
contents.  Set  state  to  MDOP. 

END  METAFILE:  Set  state  to  MFCL.  Go  to  Step  6  (Final 

Processing) . 

BEGIN  PICTURE:  Reset  all  current  picture  descriptor  variables  to 
the  corresponding  values  for  the  current  metafile  defaults. 
Save  the  contents  of  the  string  parameter  of  each  picture.  Set 
state  to  PDOP.  At  the  first  BEGIN  PICTURE,  examine  the  frequency 
count  data  to  verify  that  the  METAFILE  VERSION  and  METAFILE 
ELEMENT  LIST  elements  were  present  in  the  Metafile  Descriptor. 

BEGIN  PICTURE  BODY:  Set  state  to  PBOP. 

END  PICTURE:  Set  state  to  PICL. 

CMR.  Perform  the  Colour/Pattern  Usage  checks  described  in  the 
following: 
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The  colour  index  used/set/redefined  information  and  the  pattern 
index  used/set/ redefined  information  shall  be  compared  with  the 
requirements  of  MIL-D-28003.  CALS  conformance  violation  messages 
shall  be  generated,  reported,  and  counted,  under  the  following 
circumstances : 

(a)  Not  all  colour  indexes  used  were  set,  unless  none  of  the 
indexes  were  set. 

(b)  The  colour  redefinition  list  is  non-empty. 

(c)  The  pattern  redefinition  list  is  non-empty. 

Metafile  Descriptor  Elements  (general) ;  Set  the  corresponding 
value  in  the  current  metafile  defaults  global  data  structure. 

METAFILE  DESCRIPTION:  Save  the  contents  of  the  string  parameter. 

CAT.<;.  Verify  that  the  description  contains  "MIL-D-28003/BASIC- 
1”  as  a  substring.  Verify  that  some  additional  text  is  present- 
-text  that  could  serve  to  identify  the  company  or  product. 

METAFILE  ELEMENTS  LIST:  Mark  the  element  frequency  count  global 
data  structure  with  the  opcodes  in  the  list.  Correctly  expand 
the  codes  for  "drawing  set"  and  "drawing  plus  controls  set". 

METAFILE  DEFAULTS  REPLACEMENT:  Set  state  to  MMDR.  Set  octet 
counter  (file  offset)  to  correct  value  so  that  state  can  be  set 
back  to  MDOP  when  all  the  parameters  for  this  element  have  been 
processed  (see  Step  2  discussion) . 

CATS-  FONT  LIST;  All  the  font  names  encountered  in  the  font  list 
must  match  one  of  the  sixteen  Hershey  font  names  specified  in 
MIL-D-28003. 

Picture  Descriptor  Elements  (general) :  Set  the  corresponding 
value  in  the  current  variables  global  data  structure  if  the  state 
is  PDOP  and  in  the  current  metafile  defaults  global  data 
structure  if  the  state  is  MMDR. 

CATS.  BACKGROUND  COLOUR.  Follow  the  same  processing  as  required 
for  colour  table  elements. 

Control  Elements  (general) :  Set  the  corresponding  value  in  the 
current  variables  global  data  structure  if  the  state  is  PBOP  and 
in  the  current  metafile  defaults  global  data  structure  if  the 
state  is  MMDR. 
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Geometric  Primitives  (general):  Check  for  any  special 
constraints  on  the  number  of  entities  expected.  For  example, 
check  for  at  least  2-point  polylines,  3-point  polygons,  and 
disjoint  polylines  with  an  even  number  of  points. 

CAI5.  GDP:  Report  an  error,  because  no  GDPs  are  registered  as 
yet . 

CMB.  The  number  of  colour  values  shall  not  exceed  1,048,576  in 
a  CELL  ARRAY  element.  The  number  of  points  in  any  metafile 
element  shall  not  exceed  1024.  No  string  parameter,  with  the 
exception  of  data  records,  shall  exceed  254  characters  in  length; 
data  records  shall  not  exceed  32767  characters. 

CATfi-  If  the  default  colour  index  for  this  type  of  primitive  is 
the  current  colour  index,  mark  the  corresponding  internal  colour 
table  entry  as  used.  If  the  entry  is  not  already  marked  as  set, 
then  generate,  record,  and  count  a  CALS  Application  Profile 
conformance  violation  if  any  other  index  has  already  been  set. 

CAT.*;.  If  this  is  a  fill-area  type  primitive,  if  the  current 
interior  style  is  "pattern,”  and  if  the  default  pattern  index  is 
the  current  pattern  index,  mark  the  corresponding  internal 
pattern  table  entry  as  used.  If  the  entry  is  not  already  marked 
as  set,  then  generate,  record,  and  count  a  CALS  Application 
Profile  conformance  advisory  (which  may  become  a  violation  in  a 
future  version  of  MIL-D-28003) . 

"not  final"  TEXT  and  RESTRICTED  TEXT:  Set  state  to  TXOP. 

"final"  APPEND  TEXT:  Set  state  to  PBOP. 

Attribute  Elements  (general) :  Set  the  corresponding  value  in  the 
current  variables  global  data  structure,  if  the  state  is  PBOP, 
and  in  the  current  metafile  defaults  global  data  structure,  if 
the  state  is  MMDR. 

CAT.*;-  The  number  of  colour  values  shall  not  exceed  2048  in  a 
pattern  table  and  256  in  a  COLOUR  TABLE  element.  No  string 
parameter,  with  the  exception  of  data  records,  shall  exceed  254 
characters  in  length;  data  records  shall  not  exceed  32767 
characters . 

CAT.*;.  Colour  Value  Selection  Elements  ( for  indexed  colour) : 
These  elements  include  LINE  COLOUR,  MARKER  COLOUR,  TEXT  COLOUR, 
FILL  COLOUR,  and  EDGE  COLOUR.  Also  included  are  the  colour  index 
aspects  of  the  corresponding  bundles,  when  the  appropriate  aspect 
source  flag  controlling  the  setting  of  colour  is  individual. 
Mark  the  corresponding  internal  colour  table  entry  as  used.  If 
the  entry  is  not  already  marked  as  set,  record  and  count  a  CALS 
Application  Profile  conformance  violation  if  any  other  index  has 
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already  been  set.  This  processing  does  not  take  place  if  the 
parser/verifier  is  in  the  MMDR  state  (that  is,  if  default  colour 
indexes  are  being  specified) . 

r-ATfi-  PATTERN  INDEX:  Mark  the  corresponding  internal  pattern 
table  entry  as  used.  If  the  entry  is  not  already  marked  as  set, 
generate,  record,  and  count  a  CALS  Application  Profile 
conformance  advisory  (which  may  become  a  violation  in  a  future 
version  of  MIL-D-28003) .  This  processing  does  not  take  place  if 
the  parser/verifier  is  in  the  MMDR  state  (that  is,  if  a  default 
pattern  index  is  being  specified) . 

cat 5;.  PATTERN  TABLE:  Save  the  pattern  in  the  internal  pattern 
table.  Mark  the  entry  as  "set."  If  the  entry  is  already  marked 
as  used  and  the  pattern  table  parameter  values  are  different  from 
the  values  already  set  in  the  internal  table,  record  this  pattern 
index  as  "redefined".  This  processing  does  not  take  place  if  the 
parser/verifier  is  in  the  MMDR  state  (that  is,  if  a  default 
pattern  table  is  being  specified) .  Note  also  that  no 
redefinition  of  pattern  table  entries  is  allowed  once  the  first 
primitive  has  been  encountered  by  the  parser. 

CATS.  COLOUR  TABLE:  Save  the  colour  values  in  the  internal 
colour  table.  Mark  the  entry  as  "set."  If  the  entry  is  already 
marked  as  used  and  the  colour  table  parameter  values  are 
different  from  the  values  already  set  in  the  internal  table, 
record  this  colour  index  as  "redefined".  This  processing  does 
not  take  place  if  the  parser/verifier  is  in  the  MMDR  state  (that 
is,  if  a  default  colour  table  is  being  specified) .  Note  also 
that  no  redefinition  of  colour  table  entries  is  allowed  once  the 
first  primitive  has  been  encountered  by  the  parser. 

CAT  Si.  ESCAPE:  Report  an  error  if  the  id  is  not  -301,  -302,  or  - 
303,  because  these  are  the  only  ESCAPES  authorized  for  use  for 
CALS. 

6-  Step  6:  Final  Processing 

Once  the  entire  CGM-under-test  has  been  interpreted,  there  are 
still  two  global  checks  that  remain  to  be  accomplished. 

(Step  6A:  Required  Elements)  The  frequency  count  data  is 
examined  to  verify  that  END  METAFILE  has  occurred. 

(Step  6B:  Correctness  of  METAFILE  ELEMENT  LIST)  The  frequency 
count  data  is  compared  with  the  elements  marked  as  a  result  of 
their  presence  in  the  METAFILE  ELEMENT  LIST  to  verify  that  every 
element  actually  present  in  the  metafile  was  mentioned  in  the 
METAFILE  ELEMENT  LIST. 
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-  step  7:  Reporting 


A  FIPS  PUB  128  conformance  report  is  produced.  The  report  should 

contain,  at  a  minimum: 

(a)  The  file  name  of  the  CGM-under-test . 

(b)  The  (logical)  size  of  the  file  in  octets. 

(c)  The  contents  of  the  string  parameters  associated  with  BEGIN 
METAFILE  and  METAFILE  DESCRIPTION  (if  present). 

(d)  A  count  of  the  number  of  pictures  present  and  the  starting 
octet  count  and  content  of  the  string  parameter  associated 
with  each  BEGIN  PICTURE. 

(e)  A  statement  of  conformance  reporting  the  total  number  of 
elements  tested  and  the  number  and  type  of  errors  found  (if 
any)  . 

(f)  Specific  error  messages  for  each  conformance  violation 
detected  along  with  information  that  permits  localization  of 
the  error  (e.g.,  element  name  and  offset  into  the  file). 

f-AT  .q  -  A  MIL-D-28003  conformance  report  supplement  should  be 

appended  to  the  basic  conformance  report.  It  should  provide: 

(a)  A  statement  of  CALS  conformance  reporting  the  number  and 
type  of  Application  Profile  errors  found  (if  any). 

(b)  Specific  error  messages  for  each  CALS  CGM  Application 
Profile  conformance  violation  detected  along  with 
information  that  permits  localization  of  the  error  (e.g., 
element  name  and  offset  into  the  file) . 
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III.  REQUIREMENTS  EXTRACTED  FROM  ISO  8632-1:1987 
A-  Explanation  of  Contents 

The  CGM  Functional  Description,  ISO  8632-1:1987,  was 
systematically  read  and  all  requirements  relating  to  the 
conformance  of  instances  of  CGMs  were  extracted.  Each  separate 
statement  of  requirements  is  assigned  a  number  and  quoted.  The 
requirement  numbers  are  assigned  sequentially  from  one  and  all 
start  with  the  letter  '*F,''  indicating  that  these  requirements 
come  from  the  CGM  Functional  Description,  Part  1.  A  suffix-- 
"a,"  "b,”  "c" — is  added  if  the  identical  requirement  is  stated 
multiple  times  in  different  places. 

A  citation  for  each  statement  (shown  in  boldface)  is  given 
according  to  the  following  scheme:  The  Part  1  clause  number  is 
provided  on  the  first  line;  on  the  second  line,  for  Clause  4  and 
Clause  6  citations,  the  paragraph  number  (p)  and  sentence 
number (s)  are  specified  as  **#p/s*',  followed  by  the  page  number  on 
which  the  text  occurs.  For  Clause  5  citations,  the  only 
difference  is  that  the  second  line  starts  with  either  a  "P"  or 
"D”,  rather  than  a  "P"  means  that  the  information  is 

contained  in  the  Parameters  section  of  the  clause  and  "D"  that 
the  information  is  contained  in  the  Description  section  of  the 
clause. 

Any  commentary  on  the  requirements  statement  is  shown  as  a  note 
enclosed  in  brackets  ([NOTE;...]). 

B.  Organization  of  Requirements 

The  requirements  are  grouped  into  eight  main  categories.  Within 
each  category,  the  requirements  are  generally  stated  in  order  of 
their  clause  number.  The  only  exception  to  this  rule  is  when  a 
requirement  is  stated  in  several  places  in  the  standard.  These 
requirement  statements  are  grouped  together. 

The  eight  categories  of  requirements  statements  are; 

Required  Elements 
Required  Order  of  Elements 

Some  Global  Constraints  on  the  Content  of  the  CGM 
Metafile  Defaults  Replacement  Requirements 
Non-final  Text  Requirements 
String  Contents  Requirements 
Genera]  Assertions  about  Parameter  Values 
Specific  Parameter  Range  Constraints 


11 


1 •  Required  Elements 

FI:  Clause  4.1 

#4/1  p.9 

A  minimal  correct  metafile  consists  of  BEGIN  METAFILE,  a  Metafile 
Descriptor  consisting  of  METAFILE  VERSION  and  METAFILE  ELEMENT 
LIST,  and  END  METAFILE. 

F2:  Clause  5.2.1 

Dl/3  p.44 

BEGIN  METAFILE  shall  occur  exactly  once  in  a  metafile. 

F3:  Clause  5.3.1 

Dl/2  p.47 

[The  METAFILE  VERSION]  element  shall  occur  in  the  Metafile 
Descriptor  of  every  metafile. 

F4:  Clause  5.3.11 

Dl/3  p.50 

METAFILE  ELEMENT  LIST  shall  occur  in  the  Metafile  Descriptor  of 
every  metafile. 


2 .  Required  Order  of  Elements 

F5 :  Clause  4 . 2 

#1/1  p.9 

Every  metafile  starts  with  a  BEGIN  METAFILE  element  . . . 

F6 :  Clause  5.2.1 

Dl/1  p.44 

[BEGIN  METAFILE]  is  the  first  element  of  a  metafile. 

F7 :  Clause  4 . 2 
#1/1  p.9 

Every  metafile  ...  ends  with  an  END  METAFILE  element. 

F8 :  Clause  5.2.2 
Dl/1  p.44 

[END  METAFILE]  is  the  last  element  of  a  metafile. 
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F9:  Clause  4.3 

#2/3  p.io 

The  CGM  contains  a  single  Metafile  Descriptor  . • .  [which] 

immediately  follows  the  BEGIN  METAFILE  element  in  a  metafile 
(with  the  possible  exception  of  intervening  external  and  escape 
elements) . 

[NOTE:  This  implies  that  Metafile  Descriptor  elements  may  appear 

only  before  the  first  BEGIN  PICTURE  element  in  the  metafile,  if 
the  metafile  contains  any  pictures.] 

FIO:  Clause  4.3 
#2/4  p.lO 

External  and  escape  elements  may  appear  anywhere  between  the 

BEGIN  METAFILE  element  and  first  BEGIN  PICTURE  element  (if  one 
exists)  and  after  the  last  END  PICTURE  element  (if  one  exists) 
and  the  END  METAFILE  element. 

Fll:  Clause  4,4 
#1/3  p.l2 

If  included  in  a  picture,  [Picture  Descriptor]  elements  shall 
appear  after  the  BEGIN  PICTURE  element  and  before  the  BEGIN 
PICTURE  BODY  element. 

F12;  Clause  5.4.1 
Dl/5  p.56 

If  used,  SCALING  MODE  shall  appear  in  the  Picture  Descriptor. 


F13:  Clause  5.4.2 
D2/4  p.56 


If  used,  COLOUR  SELECTION  MODE  shall  appear 
Descriptor. 

in  the 

Picture 

F14:  Clause  5.4.3 

D2/3  p.57 

If  used,  LINE  WIDTH 
Picture  Descriptor. 

SPECIFICATION 

MODE 

shall 

appear 

in  the 

F15:  Clause  5.4.4 

D2/3  p.57 

If  used,  MARKER  SIZE 
Picture  Descriptor. 

SPECIFICATION 

MODE 

shall 

appear 

in  the 
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FI 6:  Clause  5.4.5 
D2/3  p.57 

If  used,  EDGE  WIDTH  SPECIFICATION  MODE  shall  appear  in  the 
Picture  Descriptor. 

F17 :  Clause  4 . 4 
#1/4  p.l2 

Escape  and  external  elements  are  permitted  in  the  Picture 
Descriptor. 

F18 :  Clause  4 . 5 
#1/2  p.l4 

Control  elements  .  .  .  may  appear  in  the  picture  bodies  in  the 
metafile. 

F19:  Clause  4.9 
#1/1  p.39 

External  elements  . . .  may  appear  anywhere  in  the  CGM. 

F20:  Clause  4.10 
#Fig.  12  p.41 

Control,  Graphical  Primitive,  and  Attribute  elements  can  appear 
only  while  a  picture  is  "open,”  that  is,  between  a  BEGIN  PICTURE 
BODY  element  and  the  next  END  PICTURE  element. 

F21;  Clause  5.2.5 
D2/1  p.46 

Only  external  and  escape  elements  may  occur  between  END  PICTURE 
and  BEGIN  PICTURE  or  between  END  PICTURE  and  END  METAFILE. 


3 .  Some  Global  Constraints  on  the  Content  of  the  CGM 

F22:  Clause  4.3 
#2/1  p.lO 

The  METAFILE  ELEMENT  LIST  lists  at  least  those  standardized 
elements  that  occur  in  the  metafile. 

F23:  Clause  5.3.11 
Dl/1  p.50 

All  of  the  elements  that  may  be  encountered  in  the  metafile  and 
that  are  not  mandatory  are  listed  [in  the  METAFILE  ELEMENT  LIST]. 
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F24:  Clause  4.7.7 
#5/2  p.38 

There  is  a  Metafile  Descriptor  element,  COLOUR  VALUE  EXTENT, 
which  allows  metafile  generators  to  specify  the  minimum  and 
maximum  metafile  colour  values. 

[NOTE;  This  requirement  implies  that  all  colour  values  should  be 
checked  to  ensure  that  they  lie  in  the  range  specified  in  the 
COLOUR  VALUE  EXTENT.] 

F25:  Clause  5.3.10 
Dl/1-2  p.49 

[For  COLOUR  VALUE  EXTENT]  the  parameters  represent  an  extent 
which  bounds  the  direct  colour  values  that  will  be  encountered  in 
the  metafile.  It  need  not  represent  the  exact  extent  of  colour 
values  contained  in  the  metafile. 

F26:  Clause  5.3.9 
Dl/1  p.49 

[For  MAXIMUM  COLOUR  INDEX]  the  parameter  represents  an  upper 
bound  (not  necessarily  the  least  upper  bound)  on  colour  index 
values  that  will  be  encountered  in  the  metafile. 

[NOTE;  Therefore,  the  value  of  this  parameter  should  be  greater 
than  or  equal  to  all  colour  indices  found  in  the  metafile.] 

F27:  Clause  5.4.2 
D2/1  p.56 

Only  one  colour  mode  may  be  used  within  a  picture. 

F28;  Clause  5.4.3 
D2/1  p.57 

Only  one  line  width  mode  may  be  used  within  a  picture. 

F29‘  Clause  5.4.4 
D2/1  p.57 

Only  one  marker  size  mode  may  be  used  within  a  picture. 

F30;  Clause  5.4.5 
D2/1  p.57 

Only  one  edge  width  mode  may  be  used  within  a  picture. 
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4 .  Metafile  Defaults  Replacement  Requirements 


F31:  Clause  4.4.4 
#3/1  p.l2 

The  default  state  of  the  [VDC]  extent  .  .  .  can  be  changed  in  the 
METAFILE  DEFAULTS  REPLACEMENT  element  in  the  Metafile  Descriptor. 

F32:  Clause  4.4.5 
#1/3  p.l4 

The  default  background  colour  [can  be]  specified  in  the  METAFILE 
DEFAULTS  REPLACEMENT  element. 

F33:  Clause  5.3.12 
Pl/1  p.50 

Picture  Descriptor,  Control,  and  Attribute  elements  [may  appear 
in  the  METAFILE  DEFAULTS  REPLACEMENT  element]. 

F34:  Clause  5.3.12 
Dl/4  p.50 

Any  subset  of  the  elements  given  defaults  in  clause  6  may  be 
included  [in  the  METAFILE  DEFAULTS  REPLACEMENT  element]. 

F35:  Clause  5.3.12 
D2/3  p.50-1 

An  element  [can]  occur  more  than  once  in  the  default  replacement 
list. 
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F36:  Clause  6 
fall  p. 101-103 

By  implication  (all  non-Metaf ile-Dcscriptor  elements  mentioned  in 
Clause  6),  any  of  the  following  elements  may  appear  in  a  KETAflLE 
ELEMENTS  REPLACEMENT  element: 


SCALING  MODE 

COLOUR  SELECTION  MODE 

LINE  WIDTH  SPECIFICATION  MODE 

MARKER  SIZE  SPECIFICATION  MODE 

EDGE  WIDTH  SPECIFICATION  MODE 

VDC  EXTENT 

BACKGROUND  COLOUR 

VDC  INTEGER  PRECISION 

VDC  REAL  PRECISION 

AUXILIARV  COLOUR 

TRANSPARENCY 

CLIP  RECTANGLE 

CLIP  IlfDICATOR 

LINE  BUNDLE  INDEX 

LINE  TYPE 

LINE  WIDTH 

LINE  COLOUR 

MARKER  BUNDLE  INDEX 

MARKER  TYPE 

MARKER  SIZE 

MARKER  COLOUR 

TEXT  BUNDLE  INDEX 

TEXT  FONT  INDEX 

TEXT  PRECISION 


CHARACTER  EXPANSION  FACTOR 

CHARACTER  SPACING 

TEXT  COIXUR 

CHARACTER  HEIGHT 

CHARACTER  ORIENTATION 

TEXT  PATH 

TEXT  ALIGNMENT 

CHA^  ...  ...P  ‘'"T  INDEX 

AL.Er.NAi'E  CHARACTER  SET  INDEX 

FILL  BUNDLE  INDEX 

INTERIOR  STYLE 

FILL  COLOUR 

S'  INDEX 

PATTERN  INDEX 

EDGE  BUNDLE  INDEX 

EDGE  TYPE 

EDGE  WIDTH 

EDGE  COLOUR 

EDGE  VISIBILITY 

FILL  REFERENCE  POINT 

PATTERN  TABLE 

COLOUR  TABLE 

ASPECT  SOURCE  FLAGS 


5.  Non-final  Text  Requirements 

P37:  Clause  4. 6. 3. 2 
#2/1  p.l7 

Changes  to  the  text  attributes  TEXT  FONT  INDEX,  CHARACTER 
EXPANSION  FACTOR,  CHARACTER  SPACING,  TEXT  COLOUR,  CHARACTER 
HEIGHT,  CHARACTER  SET  INDEX,  ALTERNATE  CHARACTER  SET  INDEX,  and 
TEXT  BUNDLE  INDEX,  and  to  the  control  elements  AUXILIARY  COLOUR 
and  TRANSPARENCY  are  permitted  between  a  non-final  text  element 
and  its  succeeding  APPEND  TEXT  element. 

[NOTE:  NB:  Clause  4.7.6  and  Figure  12  (p.  41)  also  indicates 
that  TEXT  PRECISION  is  okay,  while  the  formal  grammar  (which  is 
not  part  of  the  CGM  standard)  allows  CHARACTER  ORIENTATION,  which 
is  not  mentioned  in  Clause  4.7.6  nor  in  Figure  12. j 
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F38:  Clause  4. 6. 3. 3 
#1/4  p.l7 

The  initial  [text]  element  is  always  TEXT  or  RESTRICTED  TEXT,- 
subsecjue..*.  elements  may  only  be  APPEND  TEXT. 

F39:  Clause  4.7.6 
#3/1  p.24 

The  attributes  in  the  character  representation  and  placement 
group  [TEXT  FONT  INDEX,  CHARACTER  SET  INDEX,  ALTERNATE  CHARACTER 
SET  INDEX,  TEXT  PRECISION,  CHARACTER  EXPANSION  FACTOR,  CHARACTER 
SPACING,  TEXT  COLOUR,  CHARACTER  HEIGHT,  AUXILIARY  COLOUR, 
TRANSPARENCY}  and  TEXT  BUNDLE  INDEX  may  be  changed  within  a 
string. 

F40:  Clause  4.10 
#Fig.  12  p.41 

No  elements,  other  than  the  following  list  of  elements,  may 
appear  between  a  "not  final"  TEXT  or  RESTRICTED  TEXT  element  and 
a  subsequent  "final"  APPEND  TEXT  element:  "not  final"  APPEND 

TEXT,  TEXT  FONT  INDEX,  TEXT  PRECISION,  CHARACTER  EXPANSION 
FACTOR,  CHARACTER  SPACING,  TEXT  COLOUR,  CHARACTER  HEIGHT, 
CHARACTER  SET  INDEX,  ALTERNATE  CHARACTER  SET  INDEX,  TEXT  BUNDLE 
INDEX,  AUXILIARY  COLOUR,  TRANSPARENCY. 

F41a:  Clause  5.6.4 
D3/1  p.63 

also 

P41b:  Clause  5.6.5 
D6/1  p.64 

also 

F41c;  Clause  5.6.6 
D3/1  p.65 

The  flag  parameter  is  used  to  permit  changing  the  following  text 
attributes  and  control  elements  within  a  string  which  will  be 
aligned  as  a  single  block;  TEXT  FONT  INDEX,  TEXT  PRECISION, 
CHARACTER  EXPANSION  FACTOR,  CHARACTER  SPACING,  TEXT  COLOUR, 
CHARACTER  HEIGHT,  CHARACTER  SET  INDEX,  ALTERNATE  CHARACTER  SET 
INDEX,  TEXT  BUNDLE  INDEX,  AUXILIARY  COLOUR,  and  TRANSPARENCY. 
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F42a:  Clause  5.6.4 
D4/1-3  p,63 

also 

F42b:  Clause  5.6.5 
07/ 1-3  p.64 

also 

F42c;  Clause  5.6.6 
D4/1-3  p.65 

If  the  flag  is  set  to  'not  final',  ...  only  the  attribute  setting 
elements  listed  above  are  allowed  between  this  element  and  the 
APPEND  TEXT  element.  With  the  exception  of  the  ESCAPE  element, 
no  other  metafile  elements  of  any  type  are  allowed. 


6.  String  contents  Requirements 

F43a:  Clause  5.6.4 
Dl/3  p.63 

also 

F43b:  Clause  5.6.5 
02/3  p.64 

also 

F43c:  Clause  5.6.6 
01/4  p.65 

Format  effector  control  characters  (such  as  CR,  LF,  BS,  HT,  VT, 
and  FF)  are  permitted  in  a  [TEXT]  string  but  their  interpretation 
is  implementation-dependent. 
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F44a:  Clause  5.6.4 
Dl/4  p.63 

also 

F44b:  Clause  5.6.5 
D2/4  p.64 

also 

F44c:  Clause  5.6.6 
Dl/5  p.65 

Control  characters  used  for  character  set  invocation  and 
designation  (SI,  SO,  ESC,  SS2,  and  SS3)  are  permitted  according 
to  the  setting  of  CHARACTER  CODING  ANNOUNCER. 

F45:  Clause  5.7.20 
D3/1  p.89 

If  the  appropriate  CHARACTER  CODING  ANNOUNCER  is  selected,  the  SO 
and  SI  controls  and  ISO  2022  escape  sequences  may  be  embedded 
within  the  string  parameters  of  text  elements. 


7.  General  Assertions  about  Parameter  Values 

F46:  Clause  4.3.2 
#1/3  p.io 

Two  shorthand  names  for  CGM  elements  are  also  provided  for  use 
with  the  METAFILE  ELEMENT  LIST  [element]. 

F47:  Clause  4. 3. 2.1 
#2/1  p.lO 

The  drawing  set  includes  a  set  of  listed  elements. 

F48:  Clause  4. 3. 2. 2 
#2/1  p.ll 

The  drawing  plus  control  set  includes  a  set  of  listed  elements. 

F49:  Clause  4.6.5 
#2/1  p.l9 

The  colour  values  [of  a  CELL  ARRAY  element]  are  either  direct 
colour  values  or  indexes  into  the  COLOUR  TABLE,  according  to  the 
current  COLOUR  SELECTION  MODE. 


20 


F50:  Clause  5.4.2 
D2/3  p.56 

All  occurrences  of  colour-setting  elements  (AUXILIARY  COLOUR, 
LINE  COLOUR,  MARKER  COLOUR,  FILL  COLOUR,  EDGE  COLOUR,  TEXT 
COLOUR)  as  well  as  the  colour  lists  of  CELL  ARRAY  and  PATTERN 
TABLE  shall  be  in  the  current  [colour  selection]  mode. 

F51:  Clause  4.6.5 
#2/2  p.l9 

The  colour  values  [of  a  CELL  ARRAY  element]  are  in  the  precision 
declared  by  a  'local  colour  precision’  parameter  of  the  CELL 
ARRAY  element. 

F52:  Clause  5.4.6 
D6/1  p.58 

Specification  of  [VDC]  values  outside  VDC  EXTENT  in  parameters  of 
CGM  elements  is  permitted. 

F53:  clause  5.6.9 
D3/4-5  p.69 

If  the  picture  uses  indexed  colour  selection,  then  the  form  of 
the  [local  colour  precision  CELL  ARRAY]  parameter  is  the  same  as 
that  of  COLOUR  INDEX  PRECISION.  If  the  picture  uses  direct 
colour  selection,  then  the  form  of  the  parameter  is  the  same  as 
that  of  COLOUR  PRECISION. 

F54:  Clause  5.6.32 
D3/4-5  p.96 

If  the  picture  uses  indexed  colour  selection,  then  the  form  of 
the  [local  colour  precision  PATTERN  TABLE]  parameter  is  the  same 
as  that  of  COLOUR  INDEX  PRECISION.  If  the  picture  uses  direct 
colour  selection,  then  the  form  of  the  parameter  is  the  same  as 
that  of  COLOUR  PRECISION. 


8.  Specific  Parameter  Range  Constraints 

F55:  Clause  4.11 
2/1-2  p.40 

Applications  therefore  shall  not  use  parameter  values  in  the 
reserved  ranges  for  implementation  or  private  use.  Those 
metafile  elements  that  will  be  affected  by  registration  of 
graphical  items  are:  LINE  TYPE,  MARKER  TYPE,  HATCH  STYLE,  EDGE 
TYPE,  FONT  LIST,  GEI.  CRALIZED  DRAWING  PRIMITIVE,  ESCAPE. 
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F56:  Clause  5.1 
#11/4  p-43 


Non-negative  values  [of  type  IX  parameters]  are  reserved  for 
(future)  standardization. 

F57:  Clause  5.3.1 
D2/1  p.47 

This  version  of  the  CGM  standard  is  version  one  (1). 

[NOTE:  This  implies  that  the  value  of  PI  must  always  be  "1".] 

F58:  Clause  5.6.1 
Dl/1  p.62 

[For  POLYLINE]  a  line  is  drawn  from  ...  the  next-to-last  point  to 
the  last  point. 

[NOTE:  This  might  be  taken  to  imply  that  the  number  of  points 

must  be  at  least  2.] 

F59:  Clause  5.6.2 
Dl/1  p.62 

[For  DISJOINT  POLYLINE] ,  a  line  is  drawn  from  the  starting  point 
to  the  second  point  , . . 

[NOTE;  This  might  be  taken  to  imply  that  the  number  of  points 
must  be  at  least  2.  Also,  that  there  should  be  an  even  number  of 
points  in  the  point  list.] 

F60a:  Clause  5.6.4 
D5/3  p.63 

also 

F60b:  Clause  5.6.5 
D8/3  p.64 

also 

F60c:  Clause  5.6.6 
D5/2  p.65 

Text  elements  with  a  null  string  parameter  are  legal. 
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F61:  Clause  5.6.9 
Dl/1  p.69 

In  the  general  case,  P,  Q,  and  R  [ — the  first  three  parameters  of 
CELL  ARRAY — ]  can  delimit  an  arbitrary  parallelogram. 

[NOTE:  This  implies  that  the  area  specified  by  the  vertices  P, 

Q,  and  R  should  not  be  zero.] 

F62:  Clause  5.6.9 
D4/1-2  p.69 

Legal  values  of  the  'local  colour  precision'  include  the  legal 
values  of  COLOUR  (INDEX)  PRECISION.  In  addition,  each  encoding 
defines  a  special  value,  the  'default  colour  precision 
indicator',  as  an  indicator  that  the  colour  specifiers  of  the 
[CELL  ARRAY]  element  are  to  be  encoded  in  the  COLOUR  (INDEX) 
PRECISION  of  the  metafile;  i.e.,  to  indicate  that  the  'local 
colour  precision'  defaults  to  COLOUR  (INDEX)  PRECISION. 

F63:  Clause  5.6.10 
D2/1  p.71 

Non-negative  values  of  the  [GDP]  identifier  are  reserved  for 
registration  and  future  standardization  and  negative  values  are 
available  for  private  use. 

[NOTE:  This  implies  that  0  is  not  a  legal  GDP  identifier  at  this 

time. ] 

F64:  Clause  5.6.12 
D2/1  p.72 

Valid  values  of  [a  CIRCLE  element's]  radius  are  non-negative  VDC. 

F65:  Clause  5.6.15 
D5/1  p.75 

Valid  values  of  [a  CIRCULAR  ARC  CENTRE  element's]  vector 
components  are  those  which  produce  vectors  of  non-zero  length. 

F66:  Clause  5.6.15 
D6/1  p.75 

Valid  values  of  [a  CIRCULAR  ARC  CENTRE  element's]  radius  are  non¬ 
negative  VDC. 
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F67:  Clause  5.6.16 
D7/1  p.76 

Valid  values  of  [a  CIRCULAR  ARC  CENTRE  CLOSE  element's]  vector 
components  are  those  which  produce  vectors  of  non-zero  length. 

F68:  Clause  5.6.16 
D8/1  p.76 

Valid  values  of  [a  CIRCULAR  ARC  CENTRE  CLOSE  element's]  radius 
are  non-negative  VDC. 

F69:  Clause  5.6.17 
D3/1  p.76 

Valid  values  of  the  three  specifying  points  of  the  [ELLIPSE 
element]  are  those  which  yield  three  distinct  points. 

F70;  Clause  5.6.18 
D6/1  p.77 

Valid  values  of  the  three  specifying  points  of  the  [ELLIPTICAL 
ARC  element]  ate  those  which  yield  three  distinct  points. 

F71;  Clause  5.6.18 
D7/1  p.77 

Valid  values  of  [a  ELLIPTICAL  ARC  element's]  vector  components 
are  those  which  produce  vectors  of  non-zero  length. 

F72:  Clause  5.6.19 
D7/1  p.78 

Valid  values  of  the  three  specifying  points  of  the  [ELLIPTICAL 
ARC  CLOSE  element]  are  those  which  yield  three  distinct  points. 

F73:  Clause  5.6.19 
D8/1  p.78 

Valid  values  of  [a  ELLIE>TICAL  ARC  CLOSE  element's]  vector 
components  are  those  which  produce  vectors  of  non-zero  length. 

F74:  Clause  5.7.1 
D3/1  p.79 

Legal  values  [of  line  bundle  index]  are  positive  integers. 
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F75;  Clause  5.7.2 
D5/1  p,79 

Values  [of  line  type]  above  5  are  reserved  for  registration  and 
future  standardization. 

F76:  Clause  5.7.3 
D4/1  p.80 

Valid  values  of  'line  width  specifier'  are  non-negative  VDC  if 
LINE  WIDTH  SPECIFICATION  MODE  is  'absolute'  and  non-negative 
reals  if  LINE  WIDTH  SPECIFICATION  MODE  is  'scaled.' 

F77:  Clause  5,7.5 
D3/1  p.81 

Legal  values  [of  marker  bundle  index]  are  positive  integers. 

F78:  Clause  5.7.5 
D6/1  p.81 

Values  [of  marker  type]  above  5  are  researved  for  registration  and 
future  standardization. 

F79:  Clause  5.7.7 
D4/1  p.82 

Valid  values  of  'marker  size  specifier'  are  non-negative  VDC  if 
MARKER  SIZE  SPECIFICATION  MODE  is  'absolute'  and  non-  negative 
reals  if  MARKER  SIZE  SPECIFICATION  MODE  is  'scaled.' 

F80:  Clause  5.7.9 
D3/1  p.83 

Legal  values  [of  text  bundle  index]  are  positive  integers. 

F81;  Clause  5.7.10 
D4/1  p,84 

Legal  values  of  the  font  index  parameter  are  positive  integers. 

F82:  Clause  5.7.12 
D5/1  p.85 

Legal  values  of  the  character  expansion  factor  are  non-  negative 
reals. 


25 


F83:  Clause  5.7.15 
D3/1  p.87 

Valid  values  of  'character  height'  are  non-negative  VDC. 

F84:  Clause  5.7.16 
D2/1  p.87 

Valid  values  of  the  [character  up  and  character  base]  vectors 
include  any  which  have  non-zero  length  and  are  not  collinear. 

F85:  Clause  5.7.19 
D2/1  p.89 

Legal  values  of  [the]  character  set  index  parameter  are  positive 
integers. 

F86:  Clause  5.7.20 
D2/1  p.89 

Legal  values  of  the  alternate  character  set  index  parameter  are 
positive  integers. 

F87:  Clause  5.7.21 
D2/1  p.90 

Legal  values  of  FILL  BUNDLE  INDEX  are  positive  integers. 

F88:  Clause  5.7.22 
D2/1  p.90 

If  other  non-standardized  values  of  interior  style  are  used,  they 
shall  be  given  private  values. 

[NOTE:  It  is  assumed  that  "private"  in  this  context  means 

"negative  valued."] 

F89:  Clause  5.7.24 
D7/1  p.91 

Values  [of  hatch  index]  above  6  are  reserved  for  registration  and 
future  standardization. 

F90:  Clause  5.7.25 
D5/1  p.92 

Legal  values  of  PATTERN  INDEX  are  positive  integers. 
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F91:  Clause  5.7.26 
D2/1  p.92 

Legal  values  of  EDGE  BUNDLE  INDEX  are  positive  integers. 

F92:  Clause  5.7.27 
D5/1  p.93 

Non-negative  values  of  the  [edge  type]  index  [above  5]  are 
reserved  for  [registration  and]  future  standardization. 

F93:  Clause  5.7.28 
D4/1  p.94 

Valid  values  of  'edge  width  specifier'  are  non-negative  VDC  if 
EDGE  WIDTH  SPECIFTC.tTION  MODE  is  'absolute'  and  non-negative 
reals  if  EDGE  Winr  I  SPECIFICATION  MODE  is  'scaled.' 

F94:  Clause  '‘.“  32 
D2/1  p  9o 

Legal  values  of  the  pattern  table  index  parameter  are  positive 
integers. 

F95:  Clause  5.6.32 
D4/1-2  p.96 

Legal  values  of  the  'local  colour  precision'  include  the  legal 
values  of  COLOUR  (INDEX)  PRECISION.  In  addition,  each  encoding 
defines  a  special  value,  the  'default  colour  precision 

indicator',  as  an  indicator  that  the  colour  specifiers  of  the 
[PATTERN  TABLE]  element  are  to  be  encoded  in  the  COLOUR  (INDEX) 
PRECISION  of  the  metafile;  i.e.,  to  indicate  that  the  'local 
colour  precision'  defaults  to  COLOUR  (INDEX)  PRECISION. 

F96:  Clause  5.7.33 
D3/2  p.96 

The  pattern  size  vectors  ...  define  a  parallelogram. 

[NOTE:  This  might  be  taken  to  imply  that  the  vectors  have  non¬ 

zero  length  and  are  not  collinear.] 

F97:  Clause  5.7.34 
D2/1  p.97 

Legal  values  of  the  colour  index  are  non-negative  integers. 
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F98;  Clause  5.8.1 
Dl/3  p.99 

Non-negative  values  [of  the  ESCAPE  function  identifier] 
reserved  for  registration  and  future  standardization. 

[NOTE:  This  implies  that  0  is  not  a  valid  identifier  at 

time.  ] 
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IV.  REQUIREMENTS  EXTRACTED  FROM  ISO  8632-3:1987 

A.  Explanation  of  Contents 

The  CGM  Binary  Encoding,  ISO  8632-3:1987,  was  systematically  read 
and  all  requirements  relating  to  the  conformance  of  instances  of 
binary-encoded  CGMs  were  extracted.  Each  separate  statement  of 
requirements  is  assigned  a  number  and  quoted.  The  requirement 
numbers  are  assigned  sequentially  from  one  and  all  start  with  the 
letter  "B,"  indicating  that  these  requirements  come  from  the  CGM 
Binary  Encoding,  Part  3. 

A  citation  for  each  statement  (shown  in  boldface)  is  given 
according  to  the  following  scheme:  The  Part  1  clause  number  is 
provided  on  the  first  line;  on  the  second  line,  for  Clause  4,  5, 
and  9  citations,  the  paragraph  number  (p)  and  sentence  number (s) 
are  specified  as  "#p/s'',  followed  by  the  page  number  on  which  the 
text  occurs.  For  Clause  6  citations,  the  only  difference  is  that 
the  second  line  starts  with  a  Note  number,  rather  than  a 
This  means  that  the  information  is  contained  in  a  note  on  the 
specified  page.  Similarly,  for  Clause  7  citations,  the  only 
difference  is  that  the  second  line  starts  with  a  Code  number, 
rather  than  a  This  means  that  the  information  is  contained 

on  the  specified  page  in  a  note  which  expands  upon  the 
information  in  the  tables  in  Clause  7. 

Any  commentary  on  the  requirements  statement  is  shown  as  a  note 
enclosed  in  brackets  ([NOTE:...]). 


B.  Organization  of  Requirements 

The  requirements  are  stated  in  order  of  their  clause  number. 

C.  Errors  in  the  CGM  Specification 

Two  errors  were  noted  in  ISO  8632-3:1987: 

(a)  Clause  7.3  Table  4  (p.21):  The  parameter  range  for  the 
first  METAFILE  ELEMENT  LIST  parameter  should  be  +IR  not 
++IR. 

(b)  Clause  7,3  Table  8  (p,32):  The  parameter  range  for 

CHARACTER  EXPANSION  FACTOR  should  be  ++RR  (not  +RR)  to 
be  consistent  with  the  other  Parts  of  the  CGM  standard. 
However,  it  should  be  noted  that  ++RR  is  consistent 
with  GKS  (ISO  7942)  and  the  other  Parts  of  the  CGM 
standard  are  not! 
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B1 :  Clause  4 . 3 

#1/1  p.6 

The  binary  encoding  of  the  metafile  is  a  logical  data  structure 
consisting  of  a  sequential  collection  of  bits. 

B2 :  Clause  4 . 3 

#3/2  p.6 

Metafile  elements  are  constrained  to  start  on  word  boundaries 
within  the  binary  data  structure  (this  alignment  may  necessitate 
padding  an  element  with  bits  to  a  word  boundary  if  the  parameter 
data  of  the  element  does  not  fill  to  such  a  boundary) . 

B3 ;  Clause  4 . 4 
#1/2  p.7 

Metafile  elements  are  represented  in  the  Binary  Encoding  in  one 
of  two  forms--short-f orm  commands  and  long-form  commands. 

B4 :  Clause  4 . 4 
#2/1  p.7 

The  short-form  command  always  contains  a  complete  element. 

B5 :  Clause  4 . 4 

#3/1  p.7 

The  short-form  command  only  accommodates  parameter  lists  up  to  30 
octets  in  length. 

B6:  Clause  4.4 

#3/1  p.7 

The  long-form  command  accommodates  lengths  up  to  32767  octets  per 
data  partition. 

B7 :  Clause  4 . 4 

#7/1-2  p.8 

The  first  word  of  a  long-form  command  is  identical  in  structure 
to  the  first  word  of  a  short-form  command.  The  presence  of  the 
value  mil  binary  (decimal  31)  in  the  parameter  list  length 
field  indicates  that  the  command  is  a  long-form  command. 
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B8:  Clause  4.4 

#7/3-5  p.8 

The  Command  Header  for  the  long-form  command  consists  of  twc 
words.  The  second  word  contains  the  actual  para.meter  list 
length.  The  two  header  words  are  then  followed  by  the  parameter 
list. 

B9 :  Clause  4 . 4 

#8/1-4  p.8 

The  long-form  command  allows  the  para.meter  list  to  be 
partitioned.  Bit  15  of  the  second  word  indicates  whether  the 
given  data  complete  the  element  or  .more  data  follow.  For 
subsequent  data  partitions  of  the  element,  the  first  word  of  the 
long-form  Command  Header  is  omitted;  only  the  second  word, 
containing  the  parameter  list  length,  is  gi%'cn. 

BIO;  Clause  4.4 
#8/5  p.8 

The  parameter  list  length  for  each  partition  specifies  the  length 
of  that  partition,  not  the  length  of  the  complete  element. 

Bll:  Clause  4.4 
#8/56  p.8 

The  final  partition  of  an  element  is  indicated  by  bit  15  of  the 
parameter  list  length  word  being  zero. 

B12:  Clause  4.4 
#10/7  p.8 

Unless  otherwise  stated,  the  order  of  parameters  is  as  listed  in 
clause  5  of  Part  1. 

B13:  Clause  4.4 
#11/1-2  p.8 

Every  command  is  constrained  to  begin  on  a  word  boundary.  This 
necessitates  padding  the  command  with  a  single  null  octet  at  the 
end  of  the  command  if  the  command  contains  an  odd  number  of 
octets  of  parameter  data. 

B14;  Clause  4.4 
#11/3  p.9 

In  elements  with  parameters  whose  precisions  are  shorter  than  one 
octet  (i.e.,  those  containing  a  'local  colour  precision’ 
parameter)  it  is  necessary  to  pad  the  last  data-conta ining  octet 
with  null  bits  if  the  data  do  not  fill  the  octet. 
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B15:  Clause  4.4 
#11/4  p.9 


In  all  cases,  the  parameter  list  length  is  the  count  of  octets 
actually  containing  parameter  data — it  does  not  include  the 
padding  octet  if  one  is  present.  It  is  only  at  the  end  of  a 
command  that  padding  is  performed,  with  the  single  exception  of 
the  CELL  ARRAY  element. 

B16:  Clause  4.4 
#14/1  p.9 

The  short  form  command  header  with  element  class  15,  element  id 
127,  and  parameter  list  length  0  is  reserved  for  extension  of  the 
number  of  available  element  classes  in  future  revisions  [of  the 
standard] . 

[NOT^:  This  particular  element  should  not  be  encountered  in 

version  1  metafiles.] 

B17 :  Clause  5 
#1/1-2  p.lO 

The  Binary  Encoding  of  the  CGM  uses  five  primitive  data  forms  to 
represent  the  various  abstract  data  types  used  to  describe 
parameters  in  ISO  8632/1.  [These  are  Signed  Integer  (SI)  , 
Unsigned  Integer  (UI) ,  Character  (C) ,  Fixed  Point  Real  (FX) ,  and 
Float-ng  Point  Real  (FP).] 

B18:  Clause  5 
#5/2  p.lO 

In  general,  parameters  may  align  on  odd  or  even  octet  boundaries, 
because  they  may  be  preceded  by  an  odd  or  even  number  of  octets 
of  other  parameter  data . 

B19:  Clause  5 
#5/3-4  p.lO 

Elements  containing  the  local  colour  precision  parameter  may  have 
parameters  shorter  than  one  octet.  It  is  possible  in  such  cases 
that  the  parameters  will  not  align  on  octet  boundaries. 

B20:  Clause  5.1 
#1/1  p.lO 

Signed  integers  are  represented  in  "two's  complement  format." 
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B21;  Clause  5.1 
#1/2  p.lO 

Four  precisions  may  be  specified  for  signed  integers:  8-bit,  16- 
bit,  24-bit,  and  32-bit.  Integer  coordinate  data  encoded  with 
this  primitive  data  form  do  not  use  the  8-bit  precision. 

B22 :  Clause  5 . 2 
#1/1  p.ll 

Four  precisions  may  be  specified  for  unsigned  integers:  8-bit, 
16-bit,  24-bit,  and  32-bit. 

B23:  Clause  5.3 
#1/1  p.l2 

Each  character  is  stored  in  an  octet  [with  the  i-th  character 
occupying  the  most  significant  octet  of  a  word] . 

B24:  Clause  5.4 
#1/1  p.l2 

Fixed  point  real  values  are  stored  as  two  integers;  the  first 
represents  the  "whole  part"  and  has  the  same  form  as  a  Signed 
Integer;  the  second  represents  the  "fractional  part"  and  has  the 
same  form  as  an  Unsigned  Integer. 

B25:  Clause  5.4 
#1/2  p.l2 

Two  precisions  may  be  specified  for  Fixed  Point  Reals:  32-bit  and 
64-bit. 

B26:  Clause  5.4.3 
#1/1  p.l3 

The  values  of  the  represented  [fixed  point]  real  numbers  are 
given  by  [specific  equations  in  this  clause  of  the  standard] . 

B27:  Clause  5.5 
#1/1  p.l3 

Floating  Point  Real  values  are  represented  in  the  floating  point 
format  of  ANSI/IEEE  754. 
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B28:  Clause  5.5 
#2/2  p.l3 

Two  precisions  may  be  specified  for  Floating  Point  Reals:  32-  bit 
or  64-bit. 

B29:  Clause  6 
Note  3  p.l6 

Abstract  parameter  type  Enumeration,  E,  is  encoded  identically  to 
abstract  type  Index,  IX,  at  16-bit  precision. 

B30:  Clause  6 
Note  6  p. 16-17 

A  string  is  encoded  as  a  count  (unsigned  integer)  followed  by 

characters.  The  encoding  of  the  count  is  similar  to  the  encoding 
of  length  information  for  metafile  commands  themselves.  If  the 
first  octet  is  in  the  range  0..254,  then  it  represents  the 
character  count  for  the  complete  string.  If  the  first  octet  is 
255,  then  the  next  16  bits  contain  the  character  count  and  a 
continuation  flag.  The  first  bit  is  used  as  a  continuation  flag 
(allowing  strings  longer  than  32767  characters)  and  the  next  15 
bits  represent  the  count,  0.. 32767,  for  the  partial  string.  If 
the  first  bit  is  0,  then  this  partial  string  completes  the  string 
parameter.  If  1,  then  this  partial  string  will  be  followed  by 
another. 

[NOTE:  This  implies  that  a  null  string  is  encoded  as  a  single 

octet  with  value  0 . ] 

B31:  Clause  6 
Note  10  p.l7 

Fixed  point  reals  apply  to  VDC  and  to  R  parameters  for  the 
following  elements:  line  width,  edge  width,  character  spacing, 
character  expansion  factor,  marker  size,  vertical  continuous  text 
alignment,  horizontal  continuous  text  alignment. 

[NOTE:  This  implies  that  the  metric  sc-le  factor  parameter  of 

the  SCALING  MODE  element  may  be  represented  only  as  a  Floating 
Point  Real. ] 

B32:  Clause  6 
Note  11  p.l7 

For  PACKED  [CELL  ARRAY]  mode,  each  row  of  the  cell  array  is 
represented  by  an  array  of  colour  values  without  compression. 
Each  row  starts  on  a  word  boundary. 
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B33:  Clause  6 
Note  11  p.l7 

For  RUN  LENGTH  encoding,  the  data  for  each  row  [of  the  cell 
array]  begins  on  a  word  boundary  and  consists  of  run-length- 
lists  for  runs  of  constant  colour  value. 

B34 :  Clause  7 . 2 
Code  0  p.20 

A  NO-OP  has  1  parameter,  PI,  [which  consists  of]  an  arbitrary 
sequence  of  n  octets,  n=0,l,2,... 

[NOTE:  This  implies  that  the  minimum  NO-OP  element  consists  of 

two  octets  each  with  value  0.] 

B35:  Clause  7.3 
Code  12  p.22 

METAFILE  DEFAULTS  REPLACEMENT  has  1  parameter  that  itself 
contains  metafile  elements.  The  structure  and  format  is 

identical  to  appropriate  metafile  element(s). 

[NOTE:  This  implies  that  all  word  alignment  rules  for  metafile 

elements  also  apply  to  these  elements  when  they  are  part  of  the 
parameter  to  METAFILE  DEFAULTS  REPLACEMENT.] 

B36:  Clause  7.4 
Code  1  p.24 

[The  second]  SCALING  MODE  parameter  is  a  (real)  metric  scaling 
factor  which  is  ignored  if  [the  first  parameter]  is  0. 

[NOTE:  In  Table  5,  the  real  factor  is  always  expressed  as 
floating  point  (FP) ;  fixed  point  is  not  allowed  for  this  field  or 
else  the  entry  would  have  read  R  not  FP. ] 

B37:  Clause  7.6 
Code  9  p.30 

[In  the  eighth  parameter  of  CELL  ARRAY  when  cell  representation 
mode  is  'run  length']  each  list  item  consists  of  a  cell  count 
(integer)  followed  by  a  colour  value. 
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B38:  Clause  7.7 
Code  32  p . 3  6 

[NOTE;  NB;  Unlike  CELL  ARRAY,  pattern  definitions  in  PATTERN 
TABLE  have  no  "cell  representation  mode";  that  is,  they  cannot  be 
run-length  encoded. ] 

B39:  Clause  9 
#2/1  p.41 

[A  metafile  conforms  to  this  encoding  if]  each  metafile  element 
is  coded  in  the  manner  described. 

B40:  Clause  9 
#3/1  p.4l 

[A  metafile  conforms  to  this  encoding  if]  private  metafile 
elements  are  all  coded  using  the  GDP  or  ESCAPE  metafile  elements 
as  appropriate.  Opcodes  reserved  for  future  standardization  are 
not  used  to  code  private  (non-standard)  metafile  elements. 

[NOTE;  This  implies  that  a  CGM  is  not  conforming  if  it  contains 
any  opcodes  (class/id  pairs)  not  standardized  in  ISO  8632.] 

B41:  Clause  9 
#4/1  p.41 

[A  metafile  conforms  to  this  encoding  if]  private  values  of  index 
parameters  are  all  coded  using  negative  numbers. 

B42 ;  Clause  9 
#5/1  p.4l 

[A  metafile  conforms  to  this  encoding  if]  values  specified  as 
being  "reserved  for  registration  or  future  standardization"  are 
not  used  unless  their  meaning  has  been  registered. 

[NOTE:  Because  no  new  elements  have  been  registered  or 

standardized,  no  such  values  should  be  encountered  as  yet.] 

B43:  Clause  9 
#7/1  p.41 

A  conforming  metafile  may  include,  within  the  string  parameters 
of  TEXT,  RESTRICTED  TEXT,  and  APPEND  TEXT  elements,  as  well  as 
string  parameters  within  the  data  records  of  GDP  elements,  the 
ISO  2022  controls  for  designating  and  invoking  G-  sets.  This  is 
an  alternative  way,  in  addition  to  CHARACTER  SET  INDEX,  by  which 
character  sets  for  displaying  text  strings  may  be  selected. 
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B44 :  Annex  C 
all  p. 48-50 

These  are  the  codes  used  in  the  METAFILE  ELEMENTS  LIST  element: 

0/1  through  0/5 
1/1  through  1/15 
2/1  through  2/7 
3/1  through  3/6 
4/1  through  4/19 
5/1  through  5/35 
6/1 

7/1  and  7/2. 

[NOTE:  Note  the  omission  of  0/0  (NOOP)  .  This  requirement  is 

stated  in  Annex  C,  but  it  merely  summarizes  the  contents  of  the 
Clause  7  tables,  so  it  should  be  upheld  as  a  valid  requirement.] 
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V.  REQUIREMENTS  EXTRACTED  FROM  MIL-D-28003 

A.  Explanation  of  Contents 

The  Military  Specification,  Digital  Representation  for 
Communication  of  Illustration  Data:  CGM  Application  Profile, 

MIL-D-28003  (20  December  1988),  was  systematically  read  and  all 

requirements  relating  to  the  definition  of  a  CALS  conforming 
basic  metafile  were  extracted.  Each  separate  statement  of 
requirements  is  assigned  a  number  and  quoted.  The  requirement 
numbers  are  assigned  sequentially  from  one  and  all  start  with  the 
letter  "M,"  indicating  that  these  requirements  come  from  MIL-D- 
28003,  the  Milspec  CGM  Application  Profile. 

A  citation  for  each  statement  (shown  in  boldface)  is  given 
according  to  the  following  scheme;  The  clause  number  is  provided 
on  the  first  line;  on  the  second  line,  for  most  citations,  the 
paragraph  number  (p)  and  sentence  number (s)  are  specified  as 
"#p/s'',  followed  by  the  page  number  on  which  the  text  occurs. 
For  a  few  citations,  the  only  difference  is  that  the  second  line 
starts  with  a  Table  number,  rather  than  a  This  means  that 

the  information  is  contained  in  the  specified  table  on  the 
specified  page. 

Any  commentary  on  the  requirements  statement  is  shown  as  a  note 
enclosed  within  brackets  ([NOTE:...]). 

B.  Organization  of  Requirements 

The  requirements  are  grouped  into  eight  main  categories.  Within 
each  category,  the  requirements  are  generally  stated  in  order  of 
their  clause  number.  The  only  exception  to  this  rule  is  when  a 
requirement  is  stated  in  several  places  in  the  standard.  These 
requirement  statements  are  grouped  together. 

The  eight  categories  of  requirements  statements  are: 

General  CALS 

Physical  to  Logical  Mapping 

Metafile  Structure  and  Ordering 

Parameter  Decoding 

Parameter  Ranges 

Size  Constraints 

GDP  and  ESCAPE  Elements 

Colour/Pattern  Usage  Rules. 

In  addition,  MIL-D-28003  corrects  several  editorial  errors  found 
in  ANS  X3.122  adopted  by  FIPS  PUB  128.  These  corrections  are 
placed  in  their  appropriate  category  and  marked  with  the  phrase 
(CORRECTION)  preceding  the  Clause  number  on  the  first  line  of  the 
citation. 
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1.  General  CALS 


Ml :  Clause  3 . 1 

1/5  p.5 

A  conforming  basic  metafile  shall  contain  no  elements  or 
parameters  outside  of  the  Basic  Set. 

M2 :  Clause  3.1.3 

1/1  p.7 

A  conforming  basic  metafile  shall  not  contain  scalar  values  of 
parameter  data  outside  the  ranges  specified  by  this 
specification. 

M3 :  Clause  3.1.4 
1/1  p.7 

A  conforming  basic  metafile  shall  use  only  the  CGM  Binary 
Encoding,  as  defined  in  FIPS  PUB  128,  part  3. 

M4 :  Clause  3.2.1 

1/1-2  p.7 

The  Basic  Set  shall  be  defined  by  the  limitations  on  Basic  Values 
[noted  in  subclauses  of  this  clause].  Where  an  element  is  not 
mentioned,  it  is  implied  that  the  Basic  Set  shall  include  all 
values  permitted  in  FIPS  PUB  128. 

M5 :  Clause  3.2.3 

1/1  p.ll 

The  defaults  of  all  elements  in  this  Application  Profile  shall  be 
as  specified  in  Clause  6  of  Part  1  of  FIPS  PUB  128. 

M6 :  Clause  3.2.3 

1/2  p.ll 

Conforming  basic  metafiles  are  permitted  to  contain  one  or  more 
METAFILE  DEFAULTS  REPLACEMENT  elements  to  redefine  any  of  these 
values . 


2.  Physical  to  Logical  Mapping 

M7 ;  Clause  3.1.5 
1/1  p.7 

All  basic  metafiles  conforming  to  this  specification  shall 
consist  of  80-octet  records. 
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M8 :  Clause  3.1.5 
1/2  p.7 

When  [conforming  basic  meta] files  are  being  transmitted  on 
magnetic  tape,  the  80-octet  logical  records  shall  be  blocked  into 
800-octet  physical  records. 


3 .  Metafile  Structure  and  Ordering 

M9:  (CORRECTION)  Clause  3.1.6 

5/1  p.7 

Metafile  Descriptor  elements  .  .  .  shall  not  be  included  in  the 
METAFILE  DEFAULTS  REPLACEMENT  [element]. 

MIO:  Clause  3. 2. 6.1 
1/6-7  p.l3 

If  used,  this  ESCAPE  element  (Disable  clearing  of  view  surface: 
id  -301?  data  record  null)  must  appear  in  the  Metafile 

Descriptor.  This  ESCAPE  element  shall  be  a  basic  capability  of 
the  CGM  Application  Profile  under  this  specification. 

Mil:  Clause  3. 2. 6. 2 
l/6ff  p.l3 

If  used,  this  ESCAPE  element  (Device  viewport:  id  -302;  data 

record,  a  single  string  of  text)  must  appear  in  the  Picture 
Descriptor.  This  ESCAPE  element  shall  be  a  basic  capability  of 
the  CGM  Application  Profile  under  this  specification. 

M12:  Clause  3. 2. 6. 3 
l/4ff  p.l4 

This  ESCAPE  element  (Implicit  colour  table;  id  -303;  data  record, 
a  single  string  of  text)  shall  be  allowed  in  the  Metafile 

Descriptor.  This  ESCAPE  element  shall  be  a  basic  capability  of 
the  CGM  Application  Profile  under  this  specification. 

M13:  Clause  3. 2. 7.1 
3/1-3  p.l5 

The  METAFILE  DEFAULTS  REPLACEMENT  element  shall  not  be 
partitioned.  Note  that  FIPS  PUB  128  permits  multiple  occurrences 
of  this  element,  so  that  partitioning  is  not  required. 

Partitioning  shall  be  permitted  for  all  other  elements. 
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4 .  Parameter  Decoding 


M14:  (CORRECTION)  Clause  3.1.6 
3/1  p.7 

Part  3,  p.l7,  item  11:  The  fraction  numerator  which  is  "pn  " 

should  be  "pn^^  -1". 

M15:  (CORRECTION)  Clause  3.1.6 
4/1  p.7 

Part  3,  p.26,  VDC  REAL  PRECISION:  ”3I"  should  be  '’E,2I'’. 

M16:  Clause  3.2. 1.3 
1/1-2  p.8 

Note  that  the  scale-factor  parameter  of  SCALING  MODE  is  always  a 
floating-point  number,  even  when  REAL  PRECISION  has  selected 
fixed  point  for  other  real  numbers.  It  is  not  apparent  in  FIPS 
PUB  128  what  the  precision  of  this  floating  point  parameter  is 
when  fixed  point  reals  have  been  selected:  its  precision  shall 

be  (0,9,23). 


5-  Parameter  Ranges 
M17;  Clause  3. 2. 1.1 

1/1  p.8 

The  only  constraint  on  delimiter  elements  shall  be  for  NO-OP,  and 
the  basic  values  allowed  shall  be  an  arbitrary  sequence  of  n 
octets,  n=0.. 32767. 

M18:  Clause  3. 2. 1.2 
Table  I  p.8 

The  METAFILE  DESCRIPTION  element's  string  (a)  shall  include  a 
substring  briefly  identifying  company  or  product  [and]  (b)  shall 
contain  the  substring,  "MIL-D-28003/BASIC-1" . 

M19:  Clause  3. 2. 1.2 
Table  I  p.8 

INTEGER  PRECISION  Basic  Value  is  16. 

M20:  Clause  3. 2. 1.2 
Table  I  p.8 

REAL  PRECISION  Basic  Values  are  (1,16,16)  and  (0,9,23). 
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M21:  Clause  3. 2. 1.2 
Table  I  p.8 

INDEX  PRECISION  Basic  Value  is  16. 

M22:  Clause  3. 2. 1.2 
Table  I  p.8 

COLOUR  PRECISION  Basic  Values  are  8  and  16. 

H23 :  Clause  3 . 2 . 1 . 2 
Table  I  p.8 

COLOUR  INDEX  PRECISION  Basic  Values  are  8  and  16. 

M24:  Clause  3. 2. 1.2 
Tcible  I  p.8 

For  FONT  LIST,  [up  to]  four  simultaneous  fonts  are  supported. 
The  font  names  are  selected  from  those  in  [clause]  3.2.5  (q.v.). 

M25:  Clause  3.2.5 
1/2-4  p.l2 

All  of  [the  font  names  in  Table  VI]  shall  be  considered  basic 
capabilities  of  a  basic  metafile  confonning  to  this 
specification.  Any  of  these  font  [names]  may  appear  in  the  FONT 
LIST  element  in  a  basic  metafile  that  conforms  to  this 
specification.  Font  name  shall  be  the  concatenation  of  the 
string  "HERSHEY:",  to  designate  one  of  the  Hershey  fonts,  and  a 
"name  string"  to  designate  the  particular  typeface. 


43 


M26:  Clause  3.2.5 
TeOjle  VI  p.l2 

The  Basic  font  names  are 


HERSHEY ; CARTOGRAPHIC_ROMAN 
HERSHEY : CARTOGRAPHIC_GREEK 
HERSHEY : SIMPLEX_ROMAN 
HERSHEY : SIMPLEX_GREEK 
HERS  HE Y : S IMPLEX_S  CRI PT 
HERSHEY : COMPLEX_ROMAN 
HERSHEY : COMPLEX_GREEK 
HERSHEY : COMPLEX_SCRIPT 
HERSHEY ; COMPLEX_rTALIC 
HERSHEY : COMPLEX_CYRILLIC 
HERSHEY : DUPLEX_ROMAN 
HERSHEY : TRIPLEX_ROMAN 
HERSHEY : TRIPLEX_ITALIC 
HERSHEY ; GOTHIC_GERMAN 
HERSHEY : GOTHIC_ENGLISH 
HERSHEY ; GOTHIC_ITALIAN 

M27:  Clause  3. 2. 1.2 
Table  I  p.8 

CHARACTER  SET  LIST  Basic  Value  is  a  two-element  list; 
{ (0, 4/2) , (1, 4/1) } ,  which  correspond  to  X3.4  (7-bit  ASCII)  and 
X3. 134/2  (8-bit  ASCII) . 

M28:  Clause  3. 2. 1.2 
Table  I  p.8 

CHARACTER  CODING  ANNOUNCER  Basic  Values  are  0  (Basic  7-bit)  and  1 
(Basic  8-bit) . 

M29:  Clause  3.2. 1.4 
Table  II  p.9 

VDC  INTEGER  PRECISION  Basic  Values  are  16  and  32. 

M30:  Clause  3. 2. 1.4 
Tadsle  II  p.9 

VDC  REAL  PRECISION  Basic  Values  are  (1,16,16)  (fixed)  and 
(0,9,23)  (floating  point). 
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M31:  Clause  3.2. 1.4 
Table  II  p.9 

TRANSPARENCY  Basic  Value  is  1  (on) . 

M32:  Clause  3. 2. 1.6 
Table  III  p.9-10 

LINE  BUNDLE  INDEX  Basic  Values  are  1-5. 

N33:  Clause  3. 2. 1.6 
TcOsle  III  p.9-10 

LINE  TYPE  Basic  Values  are  1-5  plus  those  defined  in  clause 

3.2.2. 1. 

M34:  Clause  3.2.2. 1 
Table  IV  p.lO 

[Ten]  additional  line  types  specified  in  table  IV  shall  apply. 
Their  CGM  parameter  values  are  the  consecutive  integers  -  11301 
through  -11310. 

M35:  Clause  3. 2. 1.6 
Table  III  p.9-10 

MARKER  BUNDLE  INDEX  Basic  Values  are  1-5. 

M36:  Clause  3. 2. 1.6 
Table  III  p.9-10 

MARKER  TYPE  Basic  Values  are  1-5. 

M37:  Clause  3. 2. 1.6 
Table  III  p.9-10 

TEXT  BUNDLE  INDEX  Basic  Values  are  1-2. 

M38;  Clause  3. 2. 1.6 
Table  III  p.9-10 

TEXT  FONT  INDEX  Basic  Values  are  1-4  and  the  character  set 
selected  shall  be  representable  in  the  font  selected. 

M39;  Clause  3-2. 1.6 
Table  III  p.9-10 

CHARACTER  SET  INDEX  Basic  Values  are  1-2  and  the  character  set 
selected  shall  be  representable  in  the  font  selected. 
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M40:  Clause  3. 2. 1.6 
Table  III  p.9-10 

ALTERNATE  CHARACTER  SET  INDEX  Basic  Values  are  1-2  ani  t‘;. 
character  set  selected  shall  be  representable  in  the  it; 
selected . 

M41;  Clause  3. 2. 1.6 
Table  III  p.9-10 

FILL  BUNDLE  INDEX  Basic  Values  are  1-5. 

M42:  Clause  3.2. 1.6 
Table  III  p.9-10 

HATCH  INDEX  Basic  Values  are  1-6  plus  the  hitch  styles  (indexes) 
defined  in  clause  3.  2. 2. 2. 

M43:  Clause  3. 2. 2. 2 
Table  V  p.ll 

[Eighteen]  additional  hatch  styles  specified  in  table  V  shall 
apply.  Their  CGM  parameter  values  are  the  consecutive  integers  - 
11401  through  -11407  and  -11’.09  through  -11418. 

M44:  Clause  3.2. 1.6 
Table  III  p.9-10 

EDGE  BUNDLE  INDEX  Basic  Values  are  1-5. 

M45:  Clause  3.2. 1.6 
Table  III  p.9-10 

EDGE  TYPE  Basic  Values  are  1-5. 

M46;  Clause  3. 2. 1.6 
Table  III  p.9-10 

PATTERN  TABLE  Basic  Values  are  (Starting  Index:  1-8:  nx,  ny :  1- 

16 )  . 

M47:  Clause  3. 2. 1.6 
Table  III  p.9-10 

COLOUR  TABLE  Basic  Values  are  those  with  start  index  in  the  range 
0-255. 

M48:  Clause  3. 2. 1.8 
1/1  p.lO 

The  "action  required"  flag  of  the  MESSAGE  element  shall  be 
restricted  to  the  value  "no  action  required". 


46 


6-  Size  Constraints 


M49:  Clause  3. 2. 8. 3 
3/1  p.l8 

The  basic  value  for  the  number  of  colour  values  that  can  appear 
in  a  colour  array  or  colour  list  parameter  shall  be:  1048576  for 
CELL  ARRAY  (one  1024x1024  image);  2048  for  PATTERN  TABLE  (eight 
16x16  patterns) ;  256  for  COLOUR  TABLE  (entries  0-255) . 

M50:  Clause  3. 2, 8. 3 
5/1  p.l8 

The  basic  value  for  the  number  of  points  and  VDC  that  can  appear 
in  parameters  for  metafile  elements  shall  be  1024. 

M51;  Clause  3. 2. 8- 3 
7/1  p.l8 

The  basic  value  for  the  length  of  an  individual  string  of 
characters  shall  be:  254  for  all  string  parameters  except  data 
records,  32767  for  data  records. 


7.  GDP  and  ESCAPE  Elements 

M52;  Clause  3.2. 1.5 
1/1  p.9 

Conforming  basic  metafiles  shall  not  contain  any  Generalized 
Drawing  Primitive  (GDP)  elements. 

M53:  Clause  3.2. 1.7 
1/1  p.lO 

CGM  application  profiles  confoirming  to  this  specification  may 
contain  only  those  ESCAPE  elements  that  are  defined  in  3.2.6. 
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M54 :  Clause  3 . 2 . 6 . 2 
3/lff  p- 13-14 

[For  ESCAPE  -302  the]  escape  data  record  [is]  a  single  string  of 
text  containing  the  specification  of  the  viewport.  Parameters  in 
the  viewport  shall  be  separated  by  at  least  one  blank  character 
and/or  a  single  comma  character.  The  decimal  point  of  the  real 
fraction  shall  be  required.  Leading  zeros  of  the  real  fraction 
shall  be  optional.  There  are  four  parameters: 

PI:  First  corner  x-coordinate.  Real  fraction  of  the  default 

device  viewport,  in  the  range  [0.0, 1.0]. 

P2 :  First  corner  y-coordinate .  Real  fraction  of  the  default 

device  viewport,  in  the  range  [0.0, 1.0]. 

P4 ;  Second  corner  x-coordinate.  Real  fraction  of  the  default 
device  viewport,  in  the  range  [0.0, 1.0]. 

P4 :  Second  corner  y-coordinate.  Real  fraction  of  the  default 

device  viewport,  in  the  range  [0.0, 1.0]. 

MSS:  Clause  3. 2. 6. 3 
1/S  P.14-1S 

The  single  integer  parameter  of  the  [-303]  ESCAPE  shall  [be  in 
the  range]  0-2.  The  default  value  shall  be  1. 

MS6:  Clause  3. 2. 6. 3 
9/1-2  p.lS 

The  [single]  integer  [parameter  of  the  -303  ESCAPE  shall  be] 
encoded  as  "clear  text,"  [e.g.,]  value  2  is  encoded  as  the  string 
comprised  of  (or  containing)  the  ASCII  character  "2". 


8 .  Colour/Pattern  Usage  Rules 

MS7:  Clause  3. 2. 1.6 
5/1-3  p.lO 

For  indexed  colour  selection,  either  all  colour  indexes  used  in 
the  metafile  shall  have  their  representations  defined  by  use  of 
the  COLOUR  TABLE  element,  or  none  shall.  A  colour  index  is 
"used"  if  it  occurs  in  an  element  selecting  a  colour  value  to  be 
applied  to  a  primitive  (LINE  COLOUR,  CELL  ARRAY,  etc.).  A  colour 
index  is  also  "used"  if  it  is  the  default  for  a  primitive 
att’-ibute  and  the  default  applies  to  a  displayed  primitive. 
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M58 :  Clause  3 . 2 . 7 . 1 
7/2  p.l6 

If  a  COLOUR  TABLE  element  defining  the  representation  of  a  given 
colour  index  appears  in  a  picture,  it  shall  appear  before 
reference  to  that  index  by  an  attribute  element  or  use  of  that 
index  by  a  graphical  primitive  element  (included  in  the  latter 
shall  be  implicit  use  of  default  colour  index  attribute  values  by 
the  first  occurrence  of  an  associated  primitive) . 

M59:  Clause  3.2.7. 1 
7/3  p.l6 

Once  a  given  colour  representation  is  defined  and  used,  it  shall 
not  be  redefined. 

M60:  Clause  3.2.7. 1 
9/2  p.l6 

If  a  PATTERN  TABLE  element  defining  the  representation  of  a  given 
pattern  index  appears  in  a  picture:  (a)  it  shall  appear  before 
explicit  reference  to  that  index  by  any  PATTERN  INDEX  element;  or 
(b)  in  the  case  of  the  default  PATTERN  INDEX,  it  shall  appear 
before  any  implicit  reference  caused  by  the  first  occurrence  of 
an  associated  filled  primitive. 

M61;  Clause  3.2.7. 1 
9/3  p.l6 

Once  a  given  pattern  representation  is  defined  and  used,  it  shall 
not  be  redefined. 
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VI.  CROSS  REFERENCE  TABLE  BETWEEN  REQUIREMENTS  AND  TESTING 

Reou i r ement  Section  Where  Recniirement  is  Represented  for  Testing 


FI 

II,  Step 

6A 

F2 

II,  Step 

6A 

F3 

II,  Step 

6A 

F4 

II,  Step 

6A 

F5 

II,  Step 

4 

F6 

II,  Step 

4 

F7 

II,  Step 

5 

F8 

II,  Step 

5 

F9 

Appendix 

A 

FIO 

Appendix 

A 

Fll 

Appendix 

A 

F12 

Appendix 

A 

F13 

Appendix 

A 

F14 

Appendix 

A 

F15 

Appendix 

A 

F16 

Appendix 

A 

F17 

Appendix 

A 

F18 

Appendix 

A 

F19 

Appendix 

A 

F20 

Appendix 

A 

F21 

Appendix 

A 

F22 

II,  Step 

6B 

F2  3 

II,  Step 

6B 

F24 

Appendix 

C,  COLOUR  VALUE  EXTENT 
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Recruirement 

Section  Where  Reouirement  is  Reoresented  for  Testino 

F25 

Appendix 

c. 

COLOUR  VALUE  EXTENT 

F26 

Appendix 

c. 

colour  index  setting  elements 

F27 

II,  Step 

5 

F28 

II,  Step 

5 

F29 

II,  Step 

5 

F30 

II,  Step 

5 

F31 

Appendix 

A 

F32 

Appendix 

A 

F33 

Appendix 

A 

F34 

Appendix 

A 

F35 

Appendix 

A 

F36 

Appendix 

A 

F37 

Appendix 

A 

F38 

Appendix 

A 

F39 

Appendix 

A 

F40 

Appendix 

A 

F41 

Appendix 

A 

F42 

Appendix 

A 

F43 

Appendix 

c. 

string  parameters  of  text  elements 

F44 

Appendix 

c. 

string  parameters  of  text  elements 

F45 

Appendix 

c. 

string  parameters  of  text  elements 

F46 

Appendix 

c. 

METAFILE  ELEMENT  LIST,  &  II,  Step  5 

F47 

Appendix 

c. 

METAFILE  ELEMENT  LIST,  &  II,  Step  5 

F48 

Appendix 

C, 

METAFILE  ELEMENT  LIST,  &  II,  Step  5 
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Requirement 

F49 


F50 


F51 


F52 

F53 

F54 

F55 


F56 

F57 

F58 

F59 

F60 

F61 

F62 

F63 

F64 

F65 

F66 

F67 

F68 

F69 

F70 


Section  Where  Requirement  is  Represented  for  Testim 

Appendix  C,  METAFILE  ELEMENT  LIST,  and 
II,  Steps  4B  and  4C 

Appendix  C,  CELL  ARRAY,  and  II,  Steps  4B  and  4C 

Appendix  C,  colour  setting  elements,  CELL  ARRAY, 
PATTERN  TABLE,  and  II,  Steps  4B  and  4C 

Appendix  C,  VDC  EXTENT 

Appendix  C,  CELL  ARRAY,  and  II,  Steps  4B  and  4C 

Appendix  C,  PATTERN  TABLE,  &  II,  Steps  4B  and  4C 

Appendix  C,  LINE  TYPE,  MARKER  TYPE,  HATCH  STYLE, 
EDGE  TYPE,  FONT  LIST,  GDP,  and  ESCAPE 

Appendix  C,  index  parameters 

Appendix  C,  METAFILE  VERSION 

Appendix  C,  POLYLINE,  and  II,  Step  5 

Appendix  C,  DISJOINT  POLYLINE,  and  II,  Step  5 

Appendix  C,  text  elements 

Appendix  C,  CELL  ARRAY 

Appendix  C,  CELL  ARRAY 

Appendix  C,  GDP 

Appendix  C,  CIRCLE 

Appendix  C,  CIRCULAR  ARC  CENTRE 

Appendix  C,  CIRCULAR  ARC  CENTRE 

Appendix  C,  CIRCULAR  ARC  CENTRE  CLOSE 

Appendix  C,  CIRCULAR  ARC  CENTRE  CLOSE 

Appendix  C,  ELLIPSE 

Appendix  C,  ELLIPTICAL  ARC 
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Recmirement 

Section  Where  Recmirement  is  Renresented  for  Testina 

F71 

Appendix 

C,  ELLIPTICAL  ARC 

F72 

Appendix 

C,  ELLIPTICAL  ARC  CLOSE 

F73 

Appendix 

C,  ELLIPTICAL  ARC  CLOSE 

F74 

Appendix 

C,  LINE  BUNDLE  INDEX 

F75 

Appendix 

C,  LINE  TYPE 

F76 

Appendix 

C,  LINE  WIDTH 

Til 

Appendix 

C,  MARKER  BUNDLE  INDEX 

F78 

Appendix 

C,  MARKER  TYPE 

F79 

Appendix 

C,  MARKER  SIZE 

F80 

Appendix 

C,  TEXT  BUNDLE  INDEX 

F81 

Appendix 

C,  FONT  INDEX 

F82 

Appendix 

C,  CHARACTER  EXPANSION  FACTOR 

F8  3 

Appendix 

C,  CHARACTER  HEIGHT 

F84 

Appendix 

C,  CHARACTER  ORIENTATION 

F85 

Appendix 

C,  CHARACTER  SET  INDEX 

F86 

Appendix 

C,  ALTERNATE  CHARACTER  SET  INDEX 

F87 

Appendix 

C,  FILL  BUNDLE  INDEX 

F88 

Appendix 

C,  INTERIOR  STYLE 

F89 

Appendix 

C,  HATCH  INDEX 

F90 

Appendix 

C,  PATTERN  INDEX 

F91 

Appendix 

C,  EDGE  BUNDLE  INDEX 

F92 

Appendix 

C,  EDGE  TYPE 

F93 

Appendix 

C,  EDGE  WIDTH 

F94 

Appendix 

C,  PATTERN  TABLE  INDEX 
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Requirement  Section  Where  Requirement  is  Represented  for  Testing 


F95 

Appendix 

C, 

PATTERN  TABLE 

F96 

Appendix 

c, 

PATTERN  SIZE 

F97 

Appendix 

c. 

COLOUR  TABLE 

F98 

Appendix 

c, 

ESCAPE 

55 


Requirement 


B1 

B2 

B3 

B4 

B5 

B6 

B7 

B8 

B9 

BIO 

Bll 

B12 

B13 

B14 

B15 

B16 

B17 

B18 

B19 

B2  0 

B21 

B22 

B23 

B24 

B25 


Section  Where  Requirement  is  Represented  for  Testin' 

II,  Step  1 

II,  Step  2 

II,  Step  2 

II,  Step  2 

II,  Step  2 

II,  Step  2 

II,  Step  2 

II,  Step  2 

II,  Step  2 

II,  Step  2 

II,  Step  2 

II,  Step  4B 

II,  Step  4B 

II,  Step  4B 

II,  Step  4B 

II,  Step  3 

II,  Step  4C 

II,  Step  4B 

II,  Step  4B 

II,  Step  4C 

Appendix  C,  signed  integers 
Appendix  C,  unsigned  integers 
II,  Step  4C 

Appendix  C,  fixed  point  reals 
Appendix  C,  fixed  point  reals 
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Section  Where  Requirement  is  Represented  for  Testin« 

Appendix  C,  fixed  point  reals 

Appendix  C,  floating  point  reals 

Appendix  C,  floating  point  reals 

Appendix  C,  enumeration  type  parameters 

Appendix  C,  strings 

Appendix  C,  fixed  point  reals 

II,  Step  4C,  for  CELL  ARRAY 

II,  Step  4C,  for  CELL  ARRAY 

Appendix  C,  NOOP 

Appendix  C,  METAFILE  ELEMENT  LIST,  &  II,  Step  4 

Appendix  C,  SCALING  MODE 

II,  Step  4C,  for  CELL  ARRAY 

II,  Step  4C 

II,  Step  3 

II,  Step  3 

Appendix  C,  index  parameters 
II,  Step  4D 

Appendix  C,  string  parameters 
Appendix  C,  METAFILE  ELEMENT  LIST 
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Reauirement 

Section  Where  Reauirement  is  Reoresented  for  Testim 

Ml 

II,  Steps  3 

and  4B 

M2 

II,  Step  4D 

M3 

II,  Steps  1 

and  2 

M4 

II,  Step  4D 

M5 

II,  Step  5 

M6 

II,  Step  5 

M7 

II,  Step  1 

M8 

II,  Step  1 

M9 

Appendix  A, 

METAFILE  DEFAULTS  REPLACEMENT 

MIO 

Appendix  A, 

ESCAPE 

Mil 

Appendix  A, 

ESCAPE 

M12 

Appendix  A, 

ESCAPE 

M13 

11,  Steps  2 

and  5 

M14 

Appendix  B, 

CELL  ARRAY 

M15 

Appendix  B, 

VDC  REAL  PRECISION 

M16 

Appendix  B, 

SCALING  MODE,  and  II,  Step  4D 

M17 

Appendix  C, 

NOOP 

M18 

Appendix  C, 

METAFILE  DESCRIPTION 

M19 

Appendix  C, 

INTEGER  PRECISION 

M20 

Appendix  C, 

REAL  PRECISION 

M21 

Appendix  C, 

INDEX  PRECISION 

M2  2 

Appendix  C, 

COLOUR  PRECISION 

M2  3 

Appendix  C, 

COLOUR  INDEX  PRECISION 

M2  4 

Appendix  C, 

FONT  LIST 

M2  5 

Appendix  C, 

FONT  LIST 
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Recruirement 

Section  Where  Reouirement  is  Reoresented  for  Testina 

M2  6 

Appendix 

c. 

FONT  LIST 

M2  7 

Appendix 

c, 

CHARACTER  SET  LIST 

M2  8 

Appendix 

c. 

CHARACTER  CODING  ANNOUNCER 

M2  9 

Appendix 

c. 

VDC  INTEGER  PRECISION 

M30 

Appendix 

c. 

VDC  REAL  PRECISION 

M31 

Appendix 

c. 

TRANSPARENCY 

M3  2 

Appendix 

c. 

LINE  BUNDLE  INDEX 

M3  3 

Appendix 

c, 

LINE  TYPE 

M34 

Appendix 

c, 

LINE  TYPE 

M3  5 

Appendix 

c. 

MARKER  BUNDLE  INDEX 

M36 

Appendix 

c, 

MARKER  TYPE 

M37 

Appendix 

C, 

TEXT  BUNDLE  INDEX 

M3  8 

Appendix 

C, 

TEXT  FONT  INDEX 

M3  9 

Appendix 

C, 

CHARACTER  SET  INDEX 

M4a 

Appendix 

C, 

ALTERNATE  CHARACTER  SET  INDEX 

M41 

Appendix 

C, 

FILL  BUNDLE  INDEX 

M42 

Appendix 

C, 

HATCH  INDEX 

M4  3 

Appendix 

c. 

HATCH  INDEX 

M4  4 

Appendix 

C, 

EDGE  BUNDLE  INDEX 

M4  5 

Appendix 

C, 

EDGE  TYPE 

M4  6 

Appendix 

C, 

PATTERN  TABLE 

M4  7 

Appendix 

C, 

COLOUR  TABLE 

M48 

Appendix 

C, 

MESSAGE 

M49 

Appendix  C,  CELL  ARRAY,  PATTERN  TABLE,  and 

COLOUR  TABLE 
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Requirement 


M50 

M51 

M52 

M53 

M54 

M55 

M56 

M57 

M58 

M59 

M60 

M61 


Section  Where  Requirement  is  Represented  for  Testin' 

Appendix  C,  point  lists 

Appendix  C,  string  parameters 

Appendix  C,  GDP,  and  II,  Step  5 

Appendix  C,  GDP,  and  II,  Step  5 

Appendix  C,  ESCAPE 

Appendix  C,  ESCAPE 

Appendix  C,  ESCAPE 

II,  Steps  4B  and  4C 

II,  Step  5 

II,  step  5 

II,  Step  5 

II,  Step  5 
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APPENDIX  A 

CGM  EIoEMENT  ORDERING  REQUIREMENTS 
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Explanation  of  Contents 


The  CGM  Functional  Description,  ISO  8632-1:1987,  contains 
requirements  regarding  the  pennitted  order  of  elements  in  a  CGM. 
These  requirements  can  best  be  summarized  by  describing  a  finite- 
state  machine. 

In  the  following,  the  states  of  the  finite-state  machine 
representing  a  CGM  conformance-checking  parcer  are  listed, 
elements  which  cause  state  transitions  are  indicated,  and  which 
elements  are  valid  in  which  states  are  indicated. 

Seven  states  are  needed: 

MFCL  Metafile  closed. 

MDOP  Metafile  Descriptor  open,  but  first  picture  not  yet 

open,  and  not  processing  a  METAFILE  DEFAULTS 
REPLACEMENT  element. 

MMDR  Metafile  Descriptor  open,  but  first  picture  not  yet 

open;  however,  are  processing  a  METAFILE  DEFAULTS 
REPLACEMENT  element. 

PDOP  Picture  Descriptor  open,  but  not  in  Picture  Body  yet. 

PBOP  Picture  Body  open,  but  not  processing  a  "not  final" 

TEXT  or  "not  final"  RESTRICTED  TEXT  element. 

TXOP  Processing  a  "not  final"  TEXT  or  "not  final" 

RESTRICTED  TEXT  element. 

PICL  First  or  subsequent  picture  closed,  but  metafile  not 

yet  closed. 

In  the  following,  all  CGM  elements  are  listed  along  with  the 
states  in  which  it  is  valid  for  them  to  occur.  Any  elements 
causing  state  transitions  are  annotated  as  (***),  and  are  in 
Doldface.  The  binary  encoding  element  class  and  id  codes  are 
also  provided. 

MIL-D-28003,  the  CALS  CGM  Application  Profile,  places  a  few 
additional  constraints  on  GDPs  and  ESCAPE  elements.  These 
cons^'raints  are  noted  with  the  phrase  (CALS)  in  the  left  margin 
and  highlighted  in  boldface. 
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0,  0 


NO-OPERATION 


MDOP  MMDR 
PBOP  TXOP 


0,  1 

BEGIN  METAFILE 

MFCL 

(***) 

Causes  transition  from  MFCL 

to 

MDOP. 

0,  2 

END  METAFILE 

MDOP 

(***) 

Causes  transition  from  MDOP 

to 

MFCL. 

Causes  transition  from  PICL 

to 

MFCL. 

0,  3 

first  BEGIN  PICTURE 

MDOP 

(***) 

Causes  transition  from  MDOP 

to 

PDOP. 

0,  3 

second  or  later  BEGIN  PICTURE 

(***) 

Causes  transition  from  PiCL 

to 

PDOP. 

0,  4 

BEGIN  PICTURE  BODY 

( ***) 

Causes  transition  from  PDOP 

to 

PBOP. 

0,  5 

END  PICTURE 

PBOP 

(***) 

Causes  transition  from  PBOP 

to 

PICL. 

1,  1 

METAFILE  VERSION 

MDOP 

1,  2 

METAFILE  DESCRIPTION 

MDOP 

1,  3 

VDC  TYPE 

MDOP 

1,  4 

INTEGER  PRECISION 

MDOP 

1,  5 

REAL  PRECISION 

MDOP 

1,  6 

INDEX  PRECISION 

MDOP 

1,  7 

COLOUR  PRECISION 

MDOP 

1,  8 

COLOUR  INDEX  PRECISION 

MDOP 

1,  9 

MAXIMUM  COLOUR  INDEX 

MDOP 

PDOP 

PICL 


PICL 


PICL 


PDOP 


64 


1, 10 

COLOUR  VALUE  EXTENT 

MDOP 

1,11 

METAFILE  ELEMENT  LIST 

MDOP 

1,12 

METAFILE  DEFAULTS  REPLACEMENT 

MDOP 

(***) 

Causes  transition  from  MDOP  to  MMDR. 

(***) 

completion  of  last  element  contained 
in  the  METAFILE  DEFAULTS  REPLACEMENT 
parameter  list  causes  transition 
from  MMDR  to  MDOP. 

1,13 

FONT  LIST 

MDOP 

1,14 

CHARACTER  SET  LIST 

MDOP 

1,15 

CHARACTER  CODING  ANNOUNCER 

MDOP 

2,  1 

SCALING  MODE 

MMDR 

PDOP 

2  ,  2 

COLOUR  SELECTION  MODE 

MMDR 

PDOP 

2,  3 

LINE  WIDTH  SPECIFICATION  MODE 

MMDR 

PDOP 

2,  4 

MARKER  SIZE  SPECIFICATION  MODE 

MMDR 

PDOP 

2,  5 

EDGE  WIDTH  SPECIFICATION  MODE 

MMDR 

PDOP 

2,  6 

VDC  EXTENT 

MMDR 

PDOP 

2,  7 

BACKGROUND  COLOUR 

MMDR 

PDOP 

3,  1 

VDC  INTEGER  PRECISION 

PBOP 

MMDR 

3,  2 

VDC  REAL  PRECISION 

PBOP 

MMDR 

3,  3 

AUXILIARY  COLOUR 

PBOP 

MMDR 

TXOP 

3,  4 

TRANSPARENCY 

PBOP 

MMDR 

TXOP 

3,  5 

CLIP  RECTANGLE 

PBOP 

MMDR 
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3 


MMDR 


,  6  CLIP  INDICATOR 

4 ,  1  POLYLINE 

4,  2  DISJOINT  POLYLINE 

4 ,  3  POLYMARKER 

4,  4  "final"  TEXT 

4,  4  "not  final"  TEXT 

(***)  Causes  transition  from  PBOP  to  TXOP. 
4,  5  "final"  RESTRICTED  TEXT 

4,  5  "not  final"  RESTRICTED  TEXT 

{***)  Causes  transition  from  PBOP  to  TXOP, 
4,  6  "not  final"  APPEND  TEXT 

4,  6  "final"  APPEND  TEXT 


PBOP 

PBOP 

PBOP 

PBOP 

PBOP 

PBOP 

PBOP 

PBOP 


(***)  Causes  transition  from  TXOP  to  PBOP. 
4 ,  7  POLYGON 

4,  8  POLYGON  SET 

4,  9  CELL  ARRAY 


PBOP 

PBOP 

PBOP 


TXOP 

TXOP 

TXOP 

TXOP 
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4,10 

GENERALIZED  DRAWING 

PRIMITIVE 

PBOP 

(CALS)  This 
metafile. 

element  is  not  permitted  in  a  basic  conforming 

4,11 

RECTANGLE 

PBOP 

4,12 

CIRCLE 

PBOP 

4,13 

CIRCULAR  ARC  3  POINT 

PBOP 

4,14 

CIRCULAR  ARC  3  POINT 

CLOSE 

PBOP 

4,15 

CIRCULAR  ARC  CENTRE 

PBOP 

4,16 

CIRCULAR  ARC  CENTER 

CLOSE 

PBOP 

4,17 

ELLIPSE 

PBOP 

4,18 

ELLIPTICAL  ARC 

PBOP 

4,19 

ELLIPTICAL  ARC  CLOSE 

PBOP 

5,  1 

LINE  BUNDLE  INDEX 

PBOP 

MMDR 

5,  2 

LINE  TYPE 

PBOP 

MMDR 

5,  3 

LINE  WIDTH 

PBOP 

MMDR 

5,  4 

LINE  COLOUR 

PBOP 

MMDR 

5,  5 

MARKER  BUNDLE  INDEX 

PBOP 

MMDR 
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5,  6  MARKER  TYPE  MMDR 

PBOP 

5,  7  MARKER  SIZE  MMDR 

PBOP 

5,  8  MARKER  COLOUR  MMDR 

PBOP 

5,  9  TEXT  BUNDLE  INDEX  MMDR 

PBOP  TXOP 

5.10  TEXT  FONT  INDEX  MMDR 

PBOP  TXOP 

5.11  TEXT  PRECISION  MMDR 

PBOP  TXOP 

5.12  CHARACTER  EXPANSION  FACTOR  MMDR 

PBOP  TXOP 

5.13  CHARACTER  SPACING  MMDR 

PBOP  TXOP 

5,3.4  TEXT  COLOUR  MMDR 

PBOP  TXOP 

5.15  CHARACTER  HEIGHT  MMDR 

PBOP  TXOP 

5.16  CHARACTER  ORIENTATION  MMDR 

PBOP 

5.17  TEXT  PATH  MMDR 

PBOP 

5.18  TEXT  ALIGNMENT  MMDR 

PBOP 

5.19  CHARACTER  SET  INDEX  MMDR 

PBOP  TXOP 

5.20  ALTERNATE  CHARACTER  SET  INDEX  MMDR 

PBOP  TXOP 

5.21  FILL  BUNDLE  INDEX  MMDR 


PBOP 
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5,22 

INTERIOR  STYLE 

MM  DR 

PBOP 

5,23 

FILL  COLOUR 

MMDR 

PBOP 

5,24 

HATCH  INDEX 

MMDR 

PBOP 

5,25 

PATTERN  INDEX 

MMDR 

PBOP 

5,26 

EDGE  BUNDLE  INDEX 

MMDR 

PBOP 

5,27 

EDGE  TYPE 

MMDR 

PBOP 

5,28 

EDGE  WIDTH 

MMDR 

PBOP 

5,29 

EDGE  COLOUR 

MMDR 

PBOP 

5,30 

EDGE  VISIBILITY 

MMDR 

PBOP 

5,31 

FILL  REFERENCE  POINT 

MMDR 

PBOP 

5,32 

PATTERN  TABLE 

MMDR 

PBOP 

5,33 

PATTERN  SIZE 

MMDR 

PBOP 

5,34 

COLOUR  TABLE 

MMDR 

PBOP 

5,35 

ASPECT  SOURCE  FLAGS 

MMDR 

PBOP 
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6 


1 


ESCAPE 


MDOP  MMDR  PDOP 
PBOP  TXOP  PICL 


(CALS)  Only  the  following  three  ESCAPES  are  peinnitted 
in  a  basic  conforming  metafile  and  only  in  the 
specified  states. 

-301  Disable  viewsurface  clear  MDOP 

-302  Device  viewport 

-303  Implicit  colour  table  MDOP 

7,  1  MESSAGE  MDOP  MMDR 

PBOP 

7,  2  APPLICATION  DATA  MDOP  MMDR 

PBOP 


PDOP 


PDOP 

PICL 

PDOP 

PICL 
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APPENDIX  B 

CGM  ELEMENT  LENGTH  REQUIREMENTS 
FROM 

ISO  8632-3:1987 
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The  CGM  Binary  Encoding,  ISO  8632-3:1987,  Clause  7,  contains  tables 
showing,  for  each  CGM  element,  the  lengths  of  their  parameter  lists. 
Length  is  expressed  as  the  number  of  octets  occupied  by  the  entire 
parameter  list,  but  excluding  the  command  header  and  any  padding  needed  to 
provide  word  alignment. 

The  length  of  each  parameter  list  is  expressed  as  a  function  of  a  number  of 
variables — among  them  are  the  various  types  and  precisions  allowed  for  each 
parameter.  For  an  arbitrary  combination  of  types  and  precisions,  the  table 
is  rather  complex  to  read  and  interpret.  However,  MIL-D-28003,  the  CGM 
Application  Profile  for  CALS,  greatly  restricts  the  number  of  types  and 
precisions  that  are  permitted  to  occur  in  a  basic  conforming  metafile. 
Conseguently ,  it  is  feasible  to  develop  a  parameter  length  table  with  many 
elements  having  a  fixed  length  and  others  limited  to  only  a  few  variations. 

Variability  in  length  is  due  to  five  major  causes: 

(1)  VDC  Type:  If  integer  (I)  ,  all  VDCs  are  2  octets  in  length;  if  real 
(R) ,  4  octets  in  length. 

(2)  Colour  Selection  Mode  and  Precision:  If  indexed .  colours  are  1  or  2 
octets  in  length;  if  direct .  they  are  3  or  6  octets,  depending  upon  the 
value  of  colour  index  (CX8/CX16)  and  colour  precision  (CD8/CD16) . 

(3)  String  Length;  Strings  are  either  n+1  or  n+3  octets  long  (depending 
on  whether  they  are  coded  using  the  short  form  or  the  long  form) ;  because 
all  strings  in  CALS  (except  the  APPLICATION  DATA  data  record)  roust  contain 
fewer  than  255  octets,  for  the  purposes  of  this  table  it  is  assumed  that 
all  strings  are  coded  with  the  short  form. 

(4)  Number  of  Items  in  List:  Several  of  the  geometric  primitive  elements 
and  some  of  the  other  elements  (e.g.,  FONT  LIST  and  ASPECT  SOURCE  FLAGS) 
consist  of  a  list  of  elements,  whose  count  is  not  directly  available.  The 
length  is  clearly  a  function  of  the  number  of  items  in  the  list. 

(5)  Local  Colour  Precision:  The  numerous  values  allowed  for  local  colour 
precision  in  the  CELL  ARRAY  and  PATTERN  TABLE  elements  make  for  great 
variation  in  the  length  of  the  parameter  list  for  these  elements. 

In  the  following,  all  CGM  elements  are  listed  along  with  their  lengths  in 
octets.  Where  the  length  is  a  function  of  other  variables,  an  expression 
giving  the  length  in  terms  of  these  other  variables  is  shown  and  a  code  is 
appended  to  shown  the  source  of  variability.  In  the  table  that  follows,  n 
is  consistently  used  to  represent  the  number  of  characters  (octets)  in  a 
string  and  m  to  represent  the  number  of  items  in  a  list;  e.g.,  for  the 
number  of  points  in  a  "poly"  geometric  primitive.  The  binary  encoding 
element  class  and  id  codes  are  also  provided  in  the  table. 
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0,  0 
0,  1 
0,  2 
0,  3 
0,  4 
0,  5 

1,  1 
1,  2 
1,  3 
1,  4 
1,  5 
1,  6 
1,  7 
1.  8 
1,  9 

1,10 

1,11 

1,12 

1.13 

1.14 

1.15 


NO-OPERATION 
BEGIN  METAFILE 
END  METAFILE 
BEGIN  PICTURE 
BEGIN  PICTURE  BODY 
END  PICTURE 

METAFILE  VERSION 
METAFILE  DESCRIPTION 
VDC  TYPE 

INTEGER  PRECISION 
REAL  PRECISION 
INDEX  PRECISION 
COLOUR  PRECISION 
COLOUR  INDEX  PRECISION 
MAXIMUM  COLOUR  INDEX 

COLOUR  VALUE  EXTENT 

METAFILE  ELEMENT  LIST 
METAFILE  DEFAULTS  REPLACEMENT 
FONT  LIST 

CHARACTER  SET  LIST 
CHARACTER  CODING  ANNOUNCER 


in 

n  +  1 
0 

n  +  1 
0 
0 

2 

n  +  1 
2 
2 
6 
2 
2 
2 

1  (CX8) 

2  (CX16) 

6  (CDS) 

12  (CD16) 

4]n  +  2 

variable 

in  *  (n+i) 

m  *  (n  +  3) 

2 
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2,  1  SCALING  MODE  6 

2,  2  COLOUR  SELECTION  MODE  2 

2,  3  LINE  WIDTH  SPECIFICATION  MODE  2 

2,  4  MARKER  SIZE  SPECIFICATION  MODE  2 

2,  5  EDGE  WIDTH  SPECIFICATION  MODE  2 

2,  6  VDC  EXTENT  8  (I) 

16  (R) 

2,  7  BACKGROUND  COLOUR  3  (CD8) 

6  (CD16) 

3,  1  VDC  INTEGER  PRECISION  2 

3,  2  VDC  REAL  PRECISION  6 

3,  3  AUXILIARY  COLOUR  3  (CDS) 

6  (CD16) 

3,  4  TRANSPARENCY  2 

3,  5  CLIP  RECTANGLE  8  'T) 

16  (R) 

3,  6  CLIP  INDICATOR  2 


4,  1  POLYLINE  4lti  (I) 

Sm  (R) 

4,  2  DISJOINT  POLYLINE  4m  (I) 

8m  (R) 

4,  3  POLYMARKER  4m  (I) 

8m  (R) 

4,  4  TEXT  7  +  n  (I) 

11  +  n  (R) 

4,  5  RESTRICTED  TEXT  11  +  n  (I) 

19  +  n  (R) 

4,  6  APPEND  TEXT  3  +  n 
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4,  7 

4,  8 

4,  9 

4.10 

4.11 

4.12 

4.13 

4 . 14 

4 . 15 

4.16 

4.17 

4. 18 

4.19 

5,  1 
5,  2 
5,  3 


POLYGON 

POLYGON  SET 

CELL  ARRAY 

GENERALIZED  DRAWING  PRIMITIVE 

RECTANGLE 

CIRCLE 

CIRCULAR  ARC  3  POINT 

CIRCULAR  ARC  3  POINT  CLOSE 

CIRCULAR  ARC  CENTRE 

CIRCULAR  ARC  CENTER  CLOSE 

ELLIPSE 

ELLIPTICAL  ARC 

ELLIPTICAL  ARC  CLOSE 


4m  ( I ) 

8m  (R) 

6m  (I) 

10m  (R) 

20  +  colour  values 
(I) 

32  +  colour  values 
(R) 

5  +  4m  +  n  ( I ) 

5  +  8m  +  n  (R) 

8  (I) 

16  (R) 

6  (I) 

10  (R) 

12  (I) 

24  (R) 

14  (I) 

26  (R) 

14  (I) 

28  (R) 

16  (T) 

30  vR) 

12  (I) 

24  (R) 

20  (I) 

32  (R) 

22  (I) 

34  (R) 


LINE 

BUNDLE  INDEX 

2 

LINE 

TYPE 

2 

LINE 

WIDTH 

2 

(I) 

4 

(R) 
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5,  4 

5,  5 
5,  6 
5,  7 

5,  8 

5,  9 

5.10 

5.11 

5.12 

5.13 

5. 14 


5.15 

5. 16 

5.17 

5.18 

5.19 

5.20 

5.21 


LINE  COLOUR 


MARKER  BUNDLE  INDEX 
MARKER  TYPE 
MARKER  SIZE 

MARKER  COLOUR 


TEXT  BUNDLE  INDEX 

TEXT  FONT  INDEX 

TEXT  PRECISION 

CHARACTER  EXPANSION  FACTOR 

CHARACTER  SPACING 

TEXT  COLOUR 


CHARACTER  HEIGHT 

CHARACTER  ORIENTATION 

TEXT  PATH 
TEXT  ALIGNMENT 
CHARACTER  SET  INDEX 
ALTERNATE  CHARACTER  SET  INDEX 
FILL  BUNDLE  INDEX 


2  I  C  X  i  ) 

3  (CDS) 

6  (CD16, 

2 

2 

2  {I) 

4  ( R ) 

3  (CX8} 

2  (CXI  6} 

3  ( CDS ) 

6  (CD16) 


4 

1  {CX3) 

2  (CX16) 

3  (CD8) 

6  (CD16) 

2  (I) 

4  (R) 

8  (I) 

16  (R) 

2 

12 

2 

2 

2 


77 


5.22 

5.23 

5.24 

5.25 

5.26 

5.27 

5.28 

5.29 

5. 30 

5.31 

5.32 

5.33 

5.34 

5.35 

6,  1 

7,  1 
7,  2 


INTERIOR  STYLE 
FILL  COLOUR 

HATCH  INDEX 
PATTERN  INDEX 
EDGE  BUNDLE  INDEX 
EDGE  TYPE 
EDGE  width 

EDGE  COLOUR 

EDGE  VISIBILITY 
FILL  REFERENCE  POINT 

PATTERN  TABLE 
PATTERN  SIZE 

COLOUR  TABLE 

ASPECT  SOURCE  FLAGS 

ESCAPE 

MESSAGE 

APPLICATION  DATA 


2 

1  {CX8) 

2  (CX16) 

3  (CDS) 

6  (CD16) 

2 

2 

2 

2 

2  (I) 

4  (R) 

1  (CX8) 

2  (CX16) 

3  (CDS) 

6  (CD16) 

2 

<5  (I) 

8  (R) 

8  colour  values 

8  (I) 

16  (R) 

1  +  3m  (CX8,CD8) 

2  +  3m  {CX16,CD8) 

1  6m  (CX8,CD16) 

2  6m  (CX16,CD16) 

4m 


3  -t-  n 


3  +  n 

3  +  n  (short  DR) 
5  +  n  (long  DR) 
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APPENDIX  C 

ALLOWABLE  PARAMETER  RANGES 
FOR 

BINARY  ENCODED  CGM  ELEMENTS 
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Element 


Parameter 


Parameter  Range 


NOOP 

(CALS) 

BEGIN  METAFILE 

(CALS) 

END  METAFILE 
BEGIN  PICTURE 

(CALS) 

BEGIN  PICTURE 
BODY 

END  PICTURE  n/a 

METAFILE 

VERSION 

METAFILE 

DESCRIPTION 

(CALS) 

VDC  TYPE 

INTEGER 

PRECISION 

(CALS) 

REAL 

PRECISION 

(CAI^) 


number  of  null-valued  octets 


length  of  string  (PI) 
contents  of  string  (PI) 


length  of  string 
n/a 

length  of  string  (PI) 
contents  of  string  (PI) 


length  of  string 
n/a 


>=  0 

<=  32767 
>=  0 

; set  of  legal 
character  codes  j 

<=  254 


>=  0 

( set  of  legal 
character  codes,' 

<=  254 


version  number  (PI) 


length  of  string  (PI) 
contents  of  string  (PI) 


length  of  string 
contents  of  string 


type  (PI) 
precision  (PI) 


format  (PI) 
field  width  1  (P2) 
field  width  2  (P3) 


=  1 


>=  0 

(set  of  legal 
character  codes) 

<=  254 
contains 

’'MIL-D-28  00  3/BASIC-1" 
and  a  product  name 

(0,1) 

{8,16,24,32  ) 


{  16) 


<0 

9 

23 , 0 

12 

52, 

1 

16 

16,1 

32 

32) 

{0 

9 

23 , 1 

16 

16) 
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Element 

INDEX 

PRECISION 

(CALS) 

COLOUR 

PRECISION 

(CALS) 

COLOUR  INDEX 
PRECISION 

(CALS) 

MAXIMUM 
COLOUR  INDEX 

(CALS) 

COLOUR  VALUE 
EXTENT 


METAFILE 
ELEMENT  LIST 


METAFILE 

DEFAULTS 

REPLACEMENT 

FONT  LIST 


(CALS) 


CHARACTER 
SET  LIST 


(CALS) 


Parameter 
precision  (Pi) 

precision  (PI) 

precision  (PI) 

index  value  (PI) 


Parameter  Range 
(8,16,24,32! 

<  16  ! 

(8,16,24,32) 

(8,  16) 
(8,16,24,32! 

{8,  16) 

>  0 


<256 

minRed  minGreen  minBlue  >=  0 

maxRed  maxGreen  maxBlue  >  corresponding 

minimum  values 


number  of  elements  (PI) 
for  each  (class/id) 
in  the  list  of  elements 


>  0 

One  of  the  valid 
class/id  pairs  or 
-1/0  or  -1,1 


n/a;  however,  within  the  span  of  the  MDR  element  only 
completely  specified  Picture  Descriptor,  Control, 
Attribute,  and  Escape  elements  are  allowed. 


for  each  string  in  the  list: 

length  of  string  (PI)  >=  0 

contents  of  string  (set  of  legal 

character  codes } 


number  of  font  names  in  list  <=  4 

length  of  each  string  <=  254 


for  each  item  in  list: 
type 

1 '^ngth  of  string  (P2) 


>=  0  AND  <=  4  or 
negative 

>  0 


{  (0,4/2) , (1,4/1)  } 
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Element 

Parameter 

Parameter  Ranqe 

CHARACTER 

CODING 

ANNOUNCER 

coding  technique 

<=  3 

(CALS) 

{0,1) 

SCALING  MODE 

mode  (PI) 

metric  scale  factor  (P2) 

iO,  1  j 

!  >  0.0  if  Pl  =  l  ) 

(CALS) 

metric  scale  factor  (P2) 

must  be  represented 
as  Floating  Point  i 
mode  is  1 

COLOUR 

SELECTION 

MODE 

mode  (Pi) 

(0,1) 

LINE  WIDTH 

SPECIFICATION 

MODE 

mode  (PI) 

(0,1) 

MARKER  SIZE 

SPECIFICATION 

MODE 

mode  (PI) 

(0,1) 

EDGE  WIDTH 

SPECIFICATION 

MODE 

mode  (PI) 

{0,1) 

VDC  EXTENT 

n/a 

BACKGROUND 

COLOUR 

Red  Green  Blue 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 

VDC  INTEGER 
PRECISION 

precision  (Pi) 

{16,24,32} 

(CALS) 

{16,  32) 

VDC  REAL 
PRECISION 

format  (Pl) 
field  width  1  (P2) 
field  width  2  (P3) 

{0  9  23 , 0  12  52 , 

1  16  16,1  32  32) 

(CALS) 

{0  9  23 , 1  16  16 ) 
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Element 


Parameter 


AUXILIARY 

COLOUR 

colour  index  (PI) 
or 

<=  maximum 
colour  index 

Red  Green  Blue 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 

TRANSPARENCY 

indicator  (PI) 

(0,1) 

(CALS) 

{  1  ) 

CLIP 

RECTANGLE 

n/a 

CLIP 

INDICATOR 

indicator  (PI) 

!  0,  1  ! 

POLYLINE 

n/a 

[would  like  number 
of  points  >=  2] 

(CALS) 

number  of  points 

<=  1024 

DISJOINT 

POLYLINE 

n/a 

[would  like  number 
of  points  to  be 
even  AND  >=  2 ] 

(CALS) 

number  of  points 

<=  1024 

POLYMARKER 

n/a 

(CALS) 

number  of  points 

<=  1024 

TEXT 

flag 

length  of  string  (PI) 
contents  of  string 

(0,11 
>=  0 

{ set  of  legal 
character  codes) 

(CAI£) 

length  of  string 

<=  254 

RESTRICTED 

TEXT 

flag 

length  of  string  (PI) 
contents  of  string 

(0,1) 

>=  0 

(set  of  legal 
character  codes) 

(CALS) 

length  of  string 

<=  254 
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Element 


Parameter 


Parameter  Range 


APPEND  TEXT  flag 

length  of  string  (PI) 
contents  of  string 


(CAIjS)  length  of  string 

POLYGON  n/a 


(CALS) 


number  of  points 


POLYGON  SET  for  each  pair  of  values  in  list: 

edge  out  flag 
for  each  polygon  in  set 


(CALS)  number  of  points 

CELL  ARRAY  P,  Q,  R  (PI,  P2 ,  P3) 

nx  (P4) 
ny  (P5) 

local  colour  precision  (P6) 

cell  rep.  mode  (P7) 
for  each  cell  colour  value; 
colour  index 
or 

Red  Green  Blue 


(CALS) 

nx  (P4) 
ny  (P5) 

GDP 

identifier  (PI) 

number  of 
length  of 

points  (P2) 

data  record  string 

(CALS) 

No  GDP  is 

allowed. 

RECTANGLE 

n/a 

(0,11 
>=  0 

{set  of  legal 
character  codes  ) 

<=  254 

[would  like  number 
of  points  >=  3] 

<=  1024 


{0,1,2,3( 

[would  like  number 
of  points  >=  3] 

<=  1024 

RQ  X  RP  /=  0 
>=  1 
>=  1 

I  0,  1,  2,  4, 
8,16,24,32) 

|0,1) 

>  0  AND  <=  max. 
colour  index 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 

<=  1024 
<=  1024 

<=  m,  where 
m  =  highest 
registered  id. 
[m=-l  now] 

>=  0 
>=  0 
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Element 

Parameter 

Parameter  Ranae 

CIRCLE 

radius  (P2) 

>=  0.0 

CIRCULAR  ARC 

n/a 

CIRCULAR  ARC 

3  POINT 

n/a 

CIRCULAR  ARC 

3  POINT  CLOSE 

close  type  (P4) 

(0,1) 

CIRCULAR  ARC 
CENTRE 

Start  vector  (P2) 

End  vector  (P3) 
radius  (P4) 

I  P2  /=  0 

1  P3  /=  0 

>=  0.0 

CIRCULAR  ARC 
CENTRE  CLOSE 

Start  vector  (P2) 

End  vector  (P3) 
radius  (P4) 
close  type  (P5) 

P2  /=  0 

P3  /=  0 

>=  0.0 
!0, 1) 

ELLIPSE 

Center  (PI) 

First  CDP  (P2) 

Second  CDP  (P3) 

PI  /=  P2 

P2  /=  P3 

P3  /=  PI 

ELLIPTICAL 

ARC 

Center  (Pi) 

First  CDP  (P2) 

Second  CDP  (P3) 

Start  vector  (P4) 

End  vector  (P5) 

PI  /=  P2 

P2  /=  P3 

P3  /=  PI 

P4  /=  0 

P5  /=  0 

ELLIPTICAL 

ARC  CLOSE 

Center  (PI) 

First  CDP  (P2) 

Second  CDP  (P3) 

Start  vector  (P4) 

End  vector  (P5) 
close  type  (P6) 

PI  /=  P2 

P2  /=  P3 

P3  /=  PI 

P4  1  /=  0 

P5  !  /=  0 

{0,1> 

LINE  BUNDLE 
INDEX 

index  (Pi) 

>  0 

(CALS) 

{1. .5) 

LINE  TYPE 

type  (PI) 

<  0  OR  { 1 . . m ) 
where  m  =  highest 
registered  or 
standardized  line  type 
[m=5  now) . 

(CALS) 

{ 1 . . 5  and 
-11301. .-11310} 

Element 


Parameter 


Parameter  Range 


LINE  WIDTH 

LINE  COLOUR 


MARKER  BUNDLE 
INDEX 

(CALS) 

MARKER  TYPE 

(CALS) 

MARKER  SIZE 

MARKER  COLOUR 


TEXT  BUNDLE 
INDEX 

(CALS) 

TEXT  FONT 
INDEX 


VDC  width  or  scale  factor 


colour  index 
or 

Red  Green  Blue 


index  (PI) 


>=  0  or  >=  0.0 
depending  on 
VDC  type  and 
specification  mode 

<=  maximum 

colour  index 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 


>  0 


type  (PI) 


VDC  size  or  scale  factor 


colour  index 
or 

Red  Green  Blue 


index  (PI) 


index  (PI) 


{ 1. .5} 

<  0  OR  { 1 . . m ) 
where  m  =  highest 
registered  or 
standard  marker 
type.  [m=5  now]. 

{  1 .  .  ! 

>=  0  or  >=  0.0 
depending  on 
VDC  type  and 
specification  mode 

<=  maximum 

colour  index 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 

>  0 


(1,2) 

>  0  [perhaps  AND 
<=  number  of 
fonts  in 
font  list] 
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Element 


Parameter 


(CALS) 

TEXT  PRECISION  precision  (PI) 

CHARACTER  expansion  factor  (Pi) 

EXPANSION 

FACTOR 

CHARACTER  n/a 

SPACING 

TEXT  COLOUR  colour  index 

or 

Red  Green  Blue 


CHARACTER  VDC  height  (PI) 

HEIGHT 


CHARACTER  character  up  vector  (Pi) 

ORIENTATION  character  base  vector  (P2) 


TEXT  PATH  path  (PI) 

text  horizontal  alignment  (PI) 

ALIGNMENT  vertical  alignment  (P2) 

CHARACTER  index  (PI) 

INDEX 


(CALS) 

ALTERNATE  index  (PI) 

CHARACTER 

SET  INDEX 


(CALS) 

FILL  BUNDLE  index  (PI) 

INDEX 


{1. .4) 
(0,1,2 
>=0.0 


<=  maximum 

colour  index 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 

>=  0  or  >=  0.0 
depending  on 
VDC  type 

I  PI  /=  0 
I  P2  /=  0 
up  X  base  /-  0 

(0,1,2,31 

(0,1,2,3,41 

{0,1,2,3,4,5,61 

>  0  [perhaps  AND  SET 
<=  number  in 

character 
set  list] 

(1,2) 

>  0  [perhaps  AND 

<=  number  in 
character 
set  list] 

(1,2) 

>  0 


Element 


Parameter  Parameter  Range 


(CALS) 

{!• .5} 

INTERIOR 

STYLE 

style  (PI) 

<=  4 

FILL  COLOUR 

colour  index 
or 

<=  maximum 

colour  index 

Red  Green  Blue 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 

HATCH  INDEX 

index  (PI) 

<  0  OR  { 1 . . m } 
where  m  =  highest 
registered  or 
standard  hatch 
index.  [m=6  now] . 

(CALS) 

{ 1 . . 6  and 
-11401. .-11407, 
-11409. .-11418) 

PATTERN 

INDEX 

index  (Pi) 

>  0 

EDGE  BUNDLE 
INDEX 

index  (PI) 

>  0 

(CALS) 

(1. .5) 

EDGE  TYPE 

type  (PI) 

<  0  OR  ( 1 . . m ) 
where  m  =  highest 
registered  or 
standardized  edge 
type.  [m=5  now]. 

(CALS) 

(1. .5) 

EDGE  WIDTH 

VDC  width  or  scale  factor 

>=  0  or  >=  0.0 
depending  on 

VDC  type  and 
specification  mode 
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Element: 


Parameter 


EDGE  COLOUR 


EDGE 

VISIBILITY 

FILL 

REFERENCE 

POINT 

PATTERN 

TABLE 


(CALS) 


PATTERN  SIZE 


COLOUR  TABLE 


colour  index 
or 

Red  Green  Blue 

visibility  (Pi) 


<=  maximum 
colour  index 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max,  colour  extent 

(0,1) 


n/a 


index  (PI) 
nx  (P2) 
ny  (P3) 

local  colour  precision  (P4) 

for  each  cell  colour  value; 
colour  index 
or 


>  0 
>=  1 
>=  1 

{  0,  1,  2,  4, 
8,16,24,32  ) 

<=  maximum 
colour  index 


Red  Green  Blue 


index  (Pi) 
nx  (P2) 
ny  (P3) 

pattern  height  vector  (PI) 
pattern  width  vector  (P2) 


starting  colour  index 

for  each  colour  to  be  loaded: 
Red  Green  Blue 


each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 


1 

<=  and  <= 

8 

1 

<=  and  <= 

16 

1 

<=  and  <= 

16 

PI 

/=  0 

P2 

/=  0 

height  x  width  /=0 

<=  maximum 
colour  index 

each  component  >= 
corresponding  min. 
colour  extent  AND 
<=  corresponding 
max.  colour  extent 
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Element 

Parameter 

Parameter  Ranae 

also 

total-number-of 
colours- loaded 
plus  starting- 
colour-  index  -  1 
should  not  > 
max.  colour  index 

(CALS) 

starting  colour  index 

<  256 

ASPECT 

SOURCE  FLAGS 

for  each  pair  of  values: 
type 
value 

{0  . .  11) 

<0,1} 

ESCAPE 

identifier  (PI) 

<=  m,  where 

m  =  highest 
registered  id. 
[ia=-l  now] 


length  of  data  record 

string 

>=  0 

(CALS) 

identifier 

{ -301. . -303 ) 

content  of  data  record 

is  prescribed 

MESSAGE 

action  flag  (Pi) 

<0,1} 

len.  of  message  string 

(P2) 

>=  0 

(CALS) 

action  flag 

(1} 

APPLICATION 

DATA 

length  of  data  record 

string 

>=  0 

(CALS) 

length  of  data  record 

string 

<=  32767 

KEY: 

II  Px  II  means  the  mathematical  NORM  of  the  vector  specified 
in  parameter  Px. 

vectorl  X  vector2  means  the  vector  cross  product 

[  ...  ]  text  in  the  square  brackets  contains  additional 

information  for  the  tester. 


/= 

means 

not  equal 

to 

<= 

means 

less  than 

or 

equal  to 

>= 

means 

greater  than 

or  equal  to 
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1. 


Foreword 


NIST/NCSL  has  in  the  past  participated  in  the  CGEM  work  through 
the  CALS  representative,  Lofton  Henderson,  on  the  ANSI  and  ISO 
committees,  and  has  continued  this  participation  in  FY89.  In 
FY89,  which  ended  on  September  30,  1989,  the  work  for  this 
project  had  three  principle  aspects:  the  working  meetings  of  thc- 
graphics  and  metafile  experts  of  ANSI  and  ISO;  inter-meeting  work 
of  preparing  and  coordinating  position  papers,  baseline  standards 
documents,  and  ballot  responses;  coordination  and  liaison  with 
the  Graphical  Registration  work. 

This  final  report  summarizes  the  progress  that  was  made  at  thc- 
working  meetings,  the  current  status  of  CGM  extensions  work, 
projected  timetables  for  completion,  and  recommendations  for 
future  work.  This  report  also  presents  details  of  key  domestic 
and  international  meetings  for  CGM  extensions  during  FV89. 
Finally,  key  documents  such  as  standards  drafts,  study  reports, 
and  US  position  papers  which  are  a  result  of  work  under  this 
contract  are  included  as  attachments. 


2.  Summary  and  Conclusions 

Previous  work  has  focussed  on  defining  the  CALS  requirements  for 
CGEM,  getting  those  requirements  endorsed  by  ANSI,  and 
introducing  those  requirements  into  the  ISO  CGM  addenda 
processing.  The  requirements  definition  and  ANSI  X3H3 

endorsement  were  largely  accomplished.  Getting  functionality 
into  CGM  Addendum  1  that  meets  some  of  the  CALS  needs  has  been 
largely  accomplished.  The  major  uncompleted  work  at  the  start  of 
this  fiscal  year  was  getting  ISO  endorsement  of  the  need  for 
further  extensions,  the  Addendum  3  project,  and  getting  technical 
work  underway  on  the  project. 

Specific  goals  for  FY89  were: 

1.  Complete  processing  of  CGM  Addendum  1. 

2.  See  Addendum  3  through  the  ISO  NWI  (New  Work  Item)  process 
and  expedite  technical  work  on  it. 

3.  Coordinate  the  CGEM  work  with  registrat.!  on  proposals  to 
insure  maximum  compatibility. 

It  appears  that  CGM  Addendum  1  will  complete  soon,  and  it  will 
have  intact  the  capabilities  that  CALS  has  been  working  to  put  in 
and  keep  in.  The  final  ISO  balloting  occurred  early  in  the  year. 
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and  there  were  few  significant  changes  as  a  result.  This  is  as 
desired;  NIST/NCSL  wished  the  content  to  be  stabilized  and 
"frozen"  and  the  processing  wrapped  up. 

Most  of  the  extensions  identified  by  CALS  requirements  studies 
are  addressed  in  Addendum  3.  At  the  start  of  the  fiscal  year  a 
formal  ISO  process  was  beginning,  under  the  leadership  of  the 
NIST  representative,  to  initiate  Addendum  3  as  an  ISO  project. 
This  process  went  exactly  on  schedule,  and  with  the  desired 
results,  and  is  just  completing  as  this  fiscal  year  completes. 
(NOTE:  There  is  one  last  step,  which  has  gotten  delayed,  but  it 
is  hoped  that  this  is  a  formality.) 

Slightly  ahead  of  schedule  a  Working  Draft  for  Addendum  3  has 
been  produced,  circulated  for  ISO  comment,  and  the  US  has  had  a 
letter  ballot  and  formulated  extensive  technical  comments. 
Assuming  adequate  resource  commitments  and  no  serious  dissension 
among  the  member  nations,  the  project  is  on  track.  According  tc 
the  schedule  in  the  New  Work  Item,  final  text  should  be  available 
in  April  1991. 

There  is  a  potential  problem  looming,  however.  NIST/NC.SL  cannot 
be  sure,  despite  the  apparent  ballot  results,  that  the  European 
members  of  SC24  share  the  same  priorities  and  are  willing  to 
commit  resources  sufficient  to  complete  the  work,  with  the 
required  content,  in  a  reasonable  timeframe.  This  should  become 
apparent  at  the  SC24  meeting  in  October  1989.  ASC  X3H3  will  have 
to  continue  to  have  a  fallback  or  contingency  -  possibly  quicr, 
domestic  processing  as  a  US  standard  -  if  it  is  estimated  that 
the  project  might  bog  down  in  ISO. 

In  addition  to  working  on  the  COM  addenda,  the  NIST/NCSL 
representative  reviewed  and  coordinated  with  the  CALS  Graphical 
Registration  proposals  during  this  fiscal  year. 


3.  Recosmendations 

Further  work  is  required  if  the  Addendum  3  project  is  actually  to 
complete  expeditiously  (or  at  all) .  It  has  been  principally  the 
NIST/NCSL  representative  who  has  been  keeping  the  work  alive  and 
on  track  in  both  ANSI  and  ISO.  Continued  participation  is 
essential . 

NIST/NCSL  will  be  monitoring  and  assessing  the  study  work  which 
is  just  commencing  to  define  what,  if  any,  3D  metafile 
requirements  exist  for  effective  support  of  the  emerging  product 
data  standards  (PDES  and  STEP  in  particular) . 
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4.  Activities  in  FY89 


The  remainder  of  this  report  contains  details  of  the  working 
meetings  and  progress  on  the  CGM  addenda  during  this  fiscal  year. 
Attachments  containing  key  documents  are  included  at  the  end. 
The  material  in  the  next  two  subsections  is  condensed  from 
previous  final  reports  on  this  subject  and  is  repeated  here  for 
reference. 


4.1  Motivation  for  CGEM 

The  CGM  standard  upon  which  MIL-D-28003  is  based,  ANS 
X3. 122-1986,  was  completed  in  1986.  It  is  a  "least  comnon 
denominator”  graphical  file  interchange  standard.  That  is,  it 
provides  a  suitable  basic  picture  interchange  format  for  diverse 
application  areas.  Its  scope  and  content  were  not  derived  from 
any  particular  application  area,  but  rather  more  from  the  content 
of  other  general  purpose  computer  graphics  standards. 

This  expedited  the  processing  of  the  standard,  at  the  cost  of 
efficiency  of  usage  in  some  application  environments.  The  CALS 
application  areas  of  technical  illustration,  technical 
publications,  and  compound  document  exchange  comprise  such 
environments.  While  experience  shows  that  even  the  current  CGM 
is  more  efficient  than  specifications  such  as  page  description 
languages  (e.g. ,  PostScript)  and  engineering  data  specifications 
(e.g.,  IGES)  for  graphical  interchange,  nevertheless  CALS 
requirements  studies  show  that  the  efficiency  and  fidelity  of 
interchange  could  be  improved  with  a  well  designed  set  of 
extensions  to  CGM. 

For  these  reasons  an  extension  process  was  commenced  in  1986 
within  ISO  SC24  to  extend  CGM  functionality  as  required  by  its 
more  advanced  metafile  application  constituents. 


4.2  Historical  Overview 

Two  addenda  were  officially  commenced  in  1986: 

o  Addendum  1:  originally  intended  to  support  certain  needs  of 
GKS,  and  replace  the  non-standard  specification  in  Annex  E 
of  GKS  (i.e.,  provide  a  GKSM,  workstation  session  capture 
metafile,  to  replace  Annex  E  of  GKS) ; 

o  Addendum  2:  originally  intended  to  support  the  metafile 
recjuirements  of  GKS-3D,  and  replace  the  non-standard  Annex  E 
of  GKS-3D. 


3 


Due  in  part  to  the  successes  of  the  work  done  in  previous  years 
for  this  task: 

o  ASC  X3H3  endorsed  and  supported  the  CGM  extensions  sought 
for  CALS. 

o  The  scope  of  Addendum  1  was  expanded  to  include  some  of 
these  extensions:  internal  symbol  libraries,  additional 
geometric  primitives,  and  basic  raster  primitives. 

o  Addendum  3  was  commenced,  to  extend  CGM  further  as  required 
by  technical  illustration,  engineering  drawing,  and 

publishing  environments. 

o  Requirements  statements  and  baseline  technical  documents  tor 
Addendum  3  were  produced  within  ANSI  and  circulated  within 
ISO  as  well.  These  materials  were  largely  derived  from  CALS 
requirements  studies  and  CALS  activities. 

o  A  Metafile  Reference  Model  was  devised  within  ANSI, 
submitted  to  and  accepted  by  ISO,  with  the  result  that  the 
content  and  targets  of  the  various  addenda  were 

significantly  reorganized  and  redefined.  Relatively 

uninteresting  GKS-related  content,  which  would  have  caused 
unnecessary  and  undesirable  complication  as  a  CGM  addendum, 
was  thereby  split  off  and  attached  to  GKS. 

The  impact  of  CALS  participation  in  the  ANSI  and  ISO  work  under 
this  and  previous  contracts  is  significant.  The  NIST/NCSL 

representative  was  the  document  editor  of  CGM  (both  the  ANSI  and 
ISO  documents) ,  has  led  and  continues  to  lead  the  CGM  work  within 
X3H3.3,  has  led  and  continues  to  lead  the  US  delegation  at  ISO 
metafile  meetings,  and  is  the  ISO  leader  of  the  Addendum  3  Study 
Period.  Without  this  participation  the  CGEM  work  would  have 
progressed  much  more  slowly,  and  in  fact  Addendum  3  might  not 
have  happened  at  all. 

At  the  start  of  FY89,  Addendum  1  was  well  advanced  in  its 
processing  and  was  expected  to  change  little  (see  the  detailed 
activity  reports  following,  however) .  Addendum  3  was  entering  a 
study  phase  in  ISO,  during  which  the  requirements  were  to  be 
studied  and  agreed  upon.  This  work  was  largely  based  on  US  work 
in  the  previous  year. 

The  following  list  summarizes  the  requirements  which  were 
identified  and  designated  as  the  scope  of  Addendum  3  at  the  start 
of  this  Addendum  3  Study  Period,  which  corresponded  roughly  with 
the  start  of  this  fiscal  year. 

1.  Internal  symbol  libraries; 
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2.  Reference  to  and  invocation  of  pre-defined  external  syr.bcl 
1 ibraries ; 

3-  Advanced  drawing  capabilities,  including: 
o  user  defined  line  type; 

o  user  defined  hatch  style; 

o  a  number  of  additional  line  types; 

o  a  number  of  additional  hatch  styles; 

o  several  types  of  spline  curves; 

o  conics  and  conic  arcs; 

o  closed  figure  primitive; 

o  arbitrary  clipping  boundary; 

4.  A  number  and  variety  of  fonts; 

5.  A  completely  new  text  model  based  on  the  work  of  ISO  954  1, 
Information  Processing--Font  and  Character  Informatjcn 
Exchange ; 

6.  Additional  raster  primitives  (and  associated  attributes  for 
image  processing) ; 


4.3  Review  of  Goals  for  FY89 

The  goals  for  the  FY89  CALS  CGEM  project  were: 

1.  Addendum  3:  completion  of  the  formal  New  Work  Item  (NWi; 

procedures  for  Addendum  3  within  ISO  and  resumption  of  the 
technical  work,  including: 

o  endorsement  of  the  need  and  content  of  CGM  Addendum  3 
by  the  CGM  Extensions  Study  Period; 

o  production  of  the  necessary  NWI  and  supporting 

Requirements  Document; 

o  initiation  of  SC24  NWI  ballot  and  processing  of 

results ; 

o  technical  work  on  the  initial  draft  of  the  functional 
content,  which  was  a  US  contribution  that  was  a  year  or 
so  old. 

2.  Addendum  1:  Finish  it  by:  circulation  of  Addendum  1  DAD 

(Draft  Addendum)  text  in  X3H3  and  generation  of  a  US 
position  on  the  SC24  DAD  ballot;  processing  the  SC24  ballot 
results  and  producing  final  text. 
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3.  Addendum  2  (3D);  Prevent  the  project  from  draining 
resources  from  the  Addendum  1  and  Addendum  3  work  until  the 
project  gets  a  well-defined  and  useful  scope.  This  may  in 
fact  happen  now  as  a  consequence  of  liaison  with  product 
data  standards  committees  within  ISO.  A  3D  graphical  file 
format  may  be  defined  to  serve  the  needs  of  STEP/PDES.  This 
would  be  a  development  of  interest  to  CALS.  However,  the 
current  Addendum  2  proposals  are  relatively  unfocused  and 
uninteresting . 


4 . 4  Key  Activities  of  1989 

These  subsections,  describing  the  key  meetings  and  other 
activities  during  the  task  period,  are  organized  first  by 
addendum  and  then  chronologically  within  each  addendum  section. 


4.4.1  Addendum  1 

4. 4. 1.1  Initial  Status  and  Goals 

At  the  close  of  work  in  FY88  the  Addendum  1  project  had  been 
split  into  two  pieces:  a  static  picture  capture  Addendum  1  to 
the  CGM  standard;  and  a  dynamic  audit  trail  metafile  Addendum  1 
to  the  GKS  standard.  This  was  in  consequence  of  Metafile 
Reference  Model  work  developed  within  X3H3.3/CGM  (the  US  metafile 
group)  under  the  leadership  of  the  NIST/NCSL  representative,  and 
carried  to  the  ISO  SC24  meeting  (Tucson,  June  1988)  .  The  split 
separated  the  parts  of  interest  to  CALS  -  CGM  Addendum  1  -  from 
functionality  to  provide  a  GKSM  capability  for  GKS  (which  is  of 
no  interest  to  CALS) .  At  the  same  ISO  meeting  it  was  also  agreed 
to  skip  a  second  round  of  PDAD  (Proposed  Draft  Addendum)  ballot 
and  go  straight  to  DAD  status  (DAD  is  the  final  processing  stage 
for  an  ISO  addendum)  .  This  was  largely  due  to  the  position  of 
the  US  delegation,  which  was  being  lead  by  the  NIST/NCSL 
representative,  and  it  saved  a  potential  9  month  delay  in 
completion  of  CGM  Addendum  1. 

At  the  beginning  of  work  in  FY  1989  then,  the  DAD  text  of  CGM 
Addendum  1  was  being  circulated  for  a  6-month  ISO  SC24  ballot, 
with  proper  handling  of  voting  and  processing  this  ballot  would 
be  the  last  processing  step  for  CGM  Addendum  1  and  its  completion 
would  be  expected  in  late  1989  or  early  1990. 


4. 4. 1.2  Houston  X3H3  Meeting 

There  was  a  meeting  of  the  ANSI  X3H3  committee  in  Houston,  17-21 
October  1988.  There  was  no  activity  of  interest  to  CALS  on  the 
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CGM  Addendum  1  project  at  this  meeting.  The  DAD  text  had  not  yet 
been  received  from  ISO.  There  was  only  announcement  and  planning 
for  an  X3H3  letter  ballot  on  the  DAD  text  when  it  arrived  in  late 
1988. 


4. 4. 1.3  DAD  Ballot  &  ANSI  Letter  Ballot 

The  DAD  text  was  received  by  the  NIST/NCSL  representative  in 
December  1988  directly  from  the  document  editor  in  England.  An 
X3H3  letter  ballot  was  prepared  and  mailed  with  the  CGM  DAD.l 
text  for  a  30-day  ballot,  to  collect  and  formulate  the  LS 
position  for  the  SC24  DAD  ballot.  The  ballot  period  was  6 
January  1989  to  6  February  1989.  The  DAD.l  document  is  similar 
to  the  text  in  Attachment  8  (Attachment  8  is  the  draft  final  text 
for  CGM  Addendum  1,  which  is  the  result  of  applying  the  DAD.l 
ballot  results  to  the  DAD.l  text).  Note  that  the  GKS  Addendum  1 
document  was  being  balloted  simultaneously,  but  has  not  been 
included  as  it  is  of  little  interest  to  CALS. 


4.4. 1.4  X3H3  Milpitas  Meeting 

There  was  a  scheduled  X3H3  meeting  in  Milpitas,  CA,  February  6- 
10,  1989.  The  agenda  for  CGM  work  was  mostly  devoted  to 
processing  the  comments  from  the  DAD.l  letter  ballot.  The  goal 
of  NIST/NCSL  for  the  US  position  was  two-fold;  there  should  be 
absolute  minimal  change  in  the  DAD.l  text,  to  avoid  forcing  a 
second  DAD  ballot;  and  the  CALS  content  of  Addendum  1  should  stay 
intact.  A  second  DAD  ballot  at  the  ISO  level  would  cause  9-12 
months  delay  in  the  completion  of  processing.  The  ISO  rules  as 
traditionally  interpreted  by  SC24  would  require  a  second  DAD 
ballot  if  there  were  any  technical  change. 

One  point  in  the  US  position  deserves  explanation.  The  US  voted 
to  remove  PIXEL  ARRAY  from  Addendum  1.  This  function  (as 
reported  in  1987)  was  one  of  the  CALS  functions  and  was  supported 
by  CALS  requirements  studies.  The  NIST/NCSL  representative 
supported  the  removal  because  the  function  had  been  formulated  in 
a  way  which  did  not  meet  CALS  requirements.  The  function  was 
taken  straight  from  the  CGI  (Computer  Graphics  Interface) 
standard,  and  had  a  parameterization  which  was  device  dependent, 
could  not  be  coordinated  with  the  other  geometric  primitives  of 
CGM,  and  was  conceptually  different  from  the  PEL  ARRAY  GDP  which 
had  been  promoted  for  Graphical  Registration. 

This  technical  deficiency  alone  was  sufficient  reason  for  removal 
of  PIXEL  ARRAY.  Opposition  and  negative  votes  were  anticipated 
from  at  least  UK  and  France  as  well. 
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Attachment  1  contains  the  US  vote  and  comments  on  the  ISO  ballot, 
which  was  formulated  at  the  Milpitas  meeting  under  the  leadership 
of  the  NIST/NCSL  representative.  Note  that  the  PIXEL  ARRAY 
comment  urges  that  it  be  reformulated  and  properly  included  in 
Addendum  3.  Note  also  that  the  US  voted  "no”.  This  is 
procedurally  required  by  ANSI  if  a  technical  (as  opposed  to 
editorial)  comment  is  being  made.  As  delegation  leader  to  the 
ISO  editing  meeting  on  Addendum  1,  the  NIST/NCSL  representative 
was  empowered  to  change  the  US  vote  to  "yes"  if  the  US  comments 
were  adequately  addressed  at  the  meeting. 

The  ISO  DAD  ballot  was  scheduled  to  end  15  June  1989,  and  results 
were  scheduled  to  be  processed  at  an  SC24/WG3  MRG  (Metafile 
Rapporteur  Group,  the  sub-group  of  WG3  responsible  for  CGM 
maintenance  and  CGM  extensions)  editing  meeting  20-25  June  1989 
in  Waikoloa,  HI. 


4. 4. 1.5  Between  Milpitas  and  Waikoloa 

Private  communication  by  electronic  mail  took  place  between  the 
NIST/NCSL  representative,  who  is  the  principle  US  metafile 
delegate  to  the  SC24/WG3  MRG,  and  the  principle  metafile 
delegates  of  the  UK  and  Germany  from  February  through  June.  It 
became  clear  that  there  were  a  number  of  "no"  votes  on  the  CGM 
DAD.l  text,  and  there  were  a  number  of  technical  issues.  This 
raised  the  possibility  that  technical  changes  would  force  another 
DAD  ballot.  The  UK  delegate  thought  it  inevitable.  The  US 
thought  it  must  be  avoided  at  all  costs,  in  part  because  the  SC24 
metafile  workers  had  to  be  freed  up  to  work  on  Addendum  3. 
Germany  agreed  with  the  US.  The  UK  finally  agreed  that  the  US 
could  make  technical  changes  and  avoid  a  second  DAD  ballot  if 
there  were  consensus  on  all  of  the  changes  as  per  ISO  rules.  For 
this  reason  the  US  circulated  and  debated  the  various  national 
positions  quite  a  bit  during  the  months  before  Waikoloa,  and  were 
in  substantial  agreement  before  the  meeting  commenced. 


4. 4. 1.6  Waikoloa  MRG  Meeting 

The  MRG  met  in  Waikoloa,  HI,  20-25  June  to  process  the  results  of 
the  DAD  ballot.  The  US  delegation  consisted  of  one  person,  the 
NIST/NCSL  representative.  The  goal  was  to  resolve  all  negative 
comments  and  get  unanimous  appr-oval,  amend  the  document  as 
agreed,  and  thereby  finish  work  or.  CGM  Addendum  1. 

The  initial  count  on  the  DAD  ballot  was:  8  approve,  5 
disapprove.  Disapproving  were  Austria,  France,  Germany,  UK,  and 
US,  in  other  words  all  the  key  countries.  The  minutes  of  the 
meeting  are  not  yet  available,  so  cannot  be  included  with  this 
report.  A  summary  is  presented  below. 
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The  negative  comments  fell  into  a  few  categories; 

o  Unhappiness  with  PIXEL  ARRAY  (nearly  unanimous) ; 

o  Divergence  between  the  specifications  of  Addendum  1  and  CGI 
where  they  overlapped  (much  of  the  functionality  of  Addendum 
1  was  borrowed  from  CGI  and  the  two  standards  were  to  remain 
identical)  ; 

o  Misunderstanding  of  the  meaning  of  some  of  the  items  in 
Addendum  1  (a  number  of  French  comments  fell  into  this 

category) . 

The  biggest  problems  during  the  six  days  of  issues  reconciliation 
and  editorial  work  came  from  attempting  to  keep  Addendum  1  and 
CGI  (and  CGM  itself!)  identical  where  they  overlap.  CALS  does 
not  consider  CGI  an  important  standard  at  this  time;  however,  in 
the  original  model  of  the  relationship  between  the  standards  CGM 
is  basically  identical  to  the  output  functions  of  CGI.  Many 
still  believe  that  this  is  a  critical  principle,  and  that 

abandoning  it  will  impose  unnecessary  burdens  on  the  computer 
graphics  industry  and  other  industries  which  rely  on  graphics 
standards.  So  effort  is  always  expended  to  keep  the  two 
together.  However,  there  seem  to  be  those  working  on  CGT  who 

have  forgotten  this  principle  or  no  longer  believe  in  it,  and 

this  creates  conflicts  such  as  occurred  at  the  Waikoloa  editing 
meeting.  The  CGI  committee  was  meeting  in  parallel  to  process 
the  results  of  its  2nd  DP  ballot  and  attempt  to  advance  it  to  DIS 
stage . 

The  worst  of  the  compatibility  problems  came  when  it  was  realized 
that  CGI  had  changed  the  method  by  which  clipping  behaved  under 
the  Copy  Segment  function  and  its  t rans forma c ion .  This  issue  is 
important  to  CALS,  because  one  of  the  main  pieces  of 
functionality  of  interest  to  CALS  is  the  Global  Segment  feature 
which  was  built  into  Addendum  1.  In  some  cases  (the  default  case 
in  fact)  the  new  CGI  model  had  a  tedious  and  complex  scheme 
whereby  clipping  rectar.gles  could  accumulate  and  become  arbitrary 
convex  polygons.  This  is  not  the  way  CALS  wants  to  use  Global 
Segments.  The  CGM  committee  was  unanimous  in  not  wanting  to  have 
this  functionality.  After  much  debate  with  the  CGI  committee, 
the  best  compromise  that  could  be  achieved  was:  repackaging  the 
functionality  in  such  a  way  that  an  application  profile  can 
easily  exclude  the  features  that  it  does  not  want. 

As  a  result  of  the  editing  meeting,  all  negatives  but  Austria’s 
were  resolved  on  CGM  Addendum  1.  Germany,  UK,  and  the  US 
participated  in  the  editing  meeting,  with  occasional  input  from 
France  and  Austria.  The  remaining  negative  from  Austria  was 
based  on  a  single  technical  objection. 
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The  editing  meeting  produced  markup  for  complete  final  text,  aral 
the  document  editor  (Anne  Mumford  of  UK)  will  have  final  t«-xt 
around  late  August. 

France  wanted  a  second  DAD  ballot  because  of  the  changes  that 
were  made.  The  US,  with  support  of  UK  and  Germany,  prcpost-j 
methodology  that  is  somewhat  unconventional  for  sC2.i  but  wiu^i 
save  another  ballot  round.  The  five  nations  represented  at.  thi- 
CGM  meeting  would  agree  that  the  Addendum  was  acceptable  w;t:, 
those  modifications  agreed  to  at  the  meeting,  and  the  doccri-nt 
editor  would  circulate  the  document  for  a  six  week  review  t  • 
verify  that  the  agreed  changes  were  properly  impiemonted.  After 
that  review  the  document  would  go  to  ISO  Central  Seer  et  a  r  .  ,i  t  w;t:, 
the  recommendation  that  it  be  made  an  internat ion.  1  standard.  It 
is  hoped  that  the  Secretariat  will  progress  the  document,  rut 
this  is  not  certain  because  there  is  an  outstanding  ruMj.tt  . 
(Austria) . 

Except  for  PIXEL  ARRA’i,  no  significant  funct ;  ona  1  1 1> 
added  to  or  deleted  from  Addendum  1,  but  sc-e 
functionality  was  repackaged.  The  processing  of 
resulted  in  the  following  changes  to  CGM  Addendum  i: 

1.  PIXEL  ARRAY  is  removed;  improved  raster  capabilities  will  be 
revisited  in  Addendum  3  and  treated  in  a  coherent  manner. 

2.  METAFILE  CATEGORY  is  removed;  the  current  basic  static 
category  is  preseirved  by  allowing  "VERSION'  1"  to  appear  ir 
the  Metafile  Descriptor.  Annex  A  is  corrected  and  made  ir.tc 
a  new  normative  Annex  J  (to  define  VERSION  1;. 

3.  In  a  repackaging  of  functionality,  clipping  is  removed  frem 
INHERITANCE  FILTER;  the  exact  same  clipping  features  are  new 
selected  by  a  new  function  CLIPPING  INHERITANCE. 

4.  The  IMPLICIT  EDGE  VISIBILITY  (a  feature  of  Closed  Figures) 
was  discovered  not  to  work  properly,  so  was  removed  and  its 
functionality  replaced  by  CONNECTING  EDGE. 

5.  A  new  datatype  NAME,  with  its  own  NAMF  PRECISION,  will 
replace  datatypes  ASN,  PN,  and  SN. 

Although  GKS  Addendum  1  (the  other  half  of  the  original  CGM 
Addendum  1  after  the  split  at  Tucson)  is  not  of  interest  to  CAI.S, 
there  was  one  result  on  its  processing  which  is  related  to  the 
CGM  Addendum  work.  The  UK  took  the  position  that  a  standard  GKSM 
is  not  needed,  and  that  its  standardization  will  confuse  the 
marketplace.  They  wanted  the  project  dropped  altogether. 
Although  sympathetic,  the  US  would  not  vote  this  position  because 
of  agreements  made  earlier  with  GKSM  supporters  to  support  the 
work  (in  return  for  them  not  holding  up  CGM). 


;ng 
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Instead  changes  were  raade  to  GKS  Addendum  1  to  make  at  conlorr. 

much  more  closely  to  the  GKS  notion  of  a  sess ion-capture 

metafile,  and  to  make  it  much  more  distinct  from  CGM  (and 

hopefully  less  likely  to  be  confused  with  CGM  in  the  real  world;. 
The  delimiters  of  the  GKSM  (GKS  Addendum  1)  were  renamed,  to 

reduce  the  chances  of  metafile  interpreters  confusing  a  GKSM  with 
a  CGM.  In  particular,  the  BEGIN  METAFILE  element  was  renamed 
BEGIN  GKS  SESSION  METAFILE,  and  given  a  unique  encoding. 
Similar  changes  were  made  for  BEGIN  PICTURE  and  END  METAFILE. 
BEGIN  PICTURE  BODY  and  END  PICTURE  were  removed.  Thus  in  any 
encoding  the  GKSM  becomes  structurally  different  and  is 
introduced  by  different  delimiters. 

One  final  note  of  interest  for  the  Waikoloa  meeting:  this  was  the 
last  meeting  for  Eckhard  Moeller,  of  Germany,  the  rapporteur  ol 
the  WG3  Metafile  Rapporteur  Group.  Anne  Mumford  of  the  UK 
assumes  the  rapporteur  position  starting  at  the  Brazil  meeting. 
The  NIST/NCSL  representative  could  probably  have  had  this 
position.  However,  chairing  the  group  compromises  the  chair's 
ability  to  influence  the  technical  content  of  the  work.  The 
latter  role  is  more  important  for  CALS,  on  the  Addendu.m  3  work, 
on  which  the  MRG  should  henceforth  be  spending  most  of  its 
effort . 


4.4. 1.7  Nashua  X3H3  Meeting 

An  X3H3  meeting  took  place  in  Nashua,  NH  during  the  week  of 
September  25-29,  1939.  There  was  no  significant  activity  on 
Addendum  1  at  this  meeting. 


4. 4. 1.8  Status  &  Remaining  Work 

The  revised  CGM  Addendum  1  document,  the  draft  final  text,  was 
received  directly  from  the  document  editor  in  England  in 
mid-September.  Some  20  copies  have  been  distributed  to  US 
experts  for  final  review  and  accuracy  checking. 

It  is  clear  that  some  parts  of  the  text  have  not  been  completed 
as  evidenced  by  the  document  editor's  cover  memo.  In  addition,  a 
new  annex  containing  a  formal  grammar  was  overlooked  altogether. 
For  these  reasons,  the  text  may  have  to  be  circulated  again  after 
these  parts  are  supplied.  If  this  is  not  done,  then  fina’  text 
will  not  be  reviewed  by  anyone  except  the  document  editor.  This 
decision  to  circulate  will  be  made  at  the  SC24/WG3  MRG  meeting  in 
October.  If  another  round  of  review  is  required,  the  final 
acceptance  of  the  text  will  be  delayed  by  another  2  months. 
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4. 4. 1.9  ANSI  Processing  of  Addendum  1 


As  shown  in  the  preceding  sections,  all  work  that  has  occurred  is 
ISO  work  towards  an  Addendum  to  the  ISO  version  of  CGM  (ISO 
8632),  with  all  US  activity  contributing  to  that  work. 
MIL-D-28003  is  based  on  FIPS  PUB  128,  which  is  identical  to  the 
US  version  of  CGM  (ANSI  X3.122).  The  US  and  ISO  versions  of  CGM 
are  in  fact  identical  in  content,  but  differ  in  editorial  style. 

An  addendum  (see  Attachment  8)  is  an  editing  script.  As  such,  it 
is  not  a  complete  standalone  document  but  consists  of  change 
directives  against  the  base  document.  To  adopt  Addendum  1  in  the 
US  would  require  a  document  editor  to  revise  the  ISO  text. 

Consequently,  ANSI  has  devised  new  procedures  which  make  it  much 
easier  to  adopt  ISO  work  automatically  as  ANSI  standards,  and  to 
designate  ISO  standards  as  ANSI  standards.  The  NIST/NCSL 
representative  is  seeking  such  a  change  on  status  for  ANSI  CGM. 
Thus,  the  current  ANSI  document  would  be  withdrawn  and  replaced 
by  the  ISO  document.  The  ANSI  and  ISO  versions  of  CGM  would  then 
be  the  same  document.  After  this  change,  ISO  Addendum  1  could  be 
adopted  directly.  The  implications  on  MIL-D-28003  should  be 
minor,  since  it  would  only  have  to  be  checked  to  make  sure  that 
page  references  are  correct,  and  that  the  proper  base  document  is 
referenced. 


4.4.2  Addendum  3 

4 . 4 . 2 . 1  Initial  Status  and  Goals 

At  the  start  of  FY89,  the  US  had  been  working  on  Addendum  3 
project  for  a  year.  In  prior  CALS  work,  the  metafile 
requirements  of  CALS  which  were  not  met  by  CGM  and  not  met  by 
Addendum  1  (or  Addendum  2)  were  identified.  An  Addendum  3  was 
proposed,  and  its  approximate  contents  were  defined.  A  strategic 
choice  was  faced:  should  this  be  expedited  as  an  ANSI  project,  or 
should  it  be  pursued  as  an  ISO  project?  Although  the  former 
would  probably  be  more  expeditious,  past  experience  has  shown 
that  if  ISO  undertook  such  work,  and  if  it  did  so  before  ANSI 
completed,  then  it  would  be  likely  that  the  ANSI  work  would  be 
put  aside  and  ANSI  would  join  the  ISO  effort.  For  this  reason, 
it  was  decided  to  pursue  the  work  aggressively  in  ISO. 

The  US  first  proposed  the  project  at  the  initial  SC24  meeting  in 
December  1987.  The  project  was  not  accepted  at  that  time. 


12 


because  SC24  procedures  and  priorities  were  in  flux,  and  there 
was  some  dispute  within  ISO  about  which  committee  should  lead  on 
the  Addendum  3  content.  Consideration  of  the  project  was 
deferred  to  a  special  study  meeting  of  SC24  procedures  which  took 
place  in  April  1988.  Primarily  due  to  lack  of  time,  the  meeting 
did  not  address  Addendum  3,  but  the  NIST/NCSL  representative  did 
get  the  point  across  that  the  US  would  undertake  the  project  on 
its  own  if  ISO  did  not  move  on  it.  At  the  SC24  plenary  in  June 
1988  a  study  group  was  established,  lead  by  the  NIST/NCSL 
representative,  to  initiate  the  project  under  new  SC24 
procedures,  get  consensus  on  its  scope,  and  coordinate  with 
parallel  study  groups  for  Improved  Graphical  Text  Model  and  for 
Product  Data  Geometry  (PDG) . 

The  parallel  study  groups  were  formed  because  their  two 
technology  areas  would  be  important  for  all  new  graphics 
standards.  The  text  model  of  all  first  generation  standards 
(CGM,  GKS,  PHIGS,  CGI)  was  acknowledged  to  be  inadequate  for 
modern  typographic,  engineering,  and  presentation  requirements. 
The  purpose  of  the  text  study  group  was  to  identify  a  new  common 
model  for  the  second  generation  of  standards,  which  would  include 
Addendum  3 . 

The  PDG  group  was  formed  for  a  similar  reason.  The  set  of 
geometric  primitives  in  most  first  generation  standards  was 
rudimentary.  CGM  was  better,  including  some  conics,  etc.  But 
modern  practice  requires  a  more  substantial  set,  including  such 
primitives  as  various  sorts  of  splines  and  full  conics.  The  PIX 
group  was  charged  with  defining  the  relationship  between  product 
data  standards  (PDES,  STEP,  etc)  and  graphics  standards.  From 
this  relationship  might  be  deduced  further  geometric  primitives 
which  should  be  in  the  graphics  standards  in  order  to  fully 
support  product  data  standards. 

The  Addendum  3  study  group  was  to  report  at  the  next  SC2  4 
plenary,  October  1989,  and  was  to  complete  all  of  the  required 
New  Work  Item  (NWI)  processing  steps  and  produce  a  Working  Draft 
(WD)  Addendum  3  by  then.  The  initial  meeting  of  the  study  group 
was  scheduled  at  the  beginning  of  FY89,  and  was  arranged  so  that 
the  two  technology  groups  (Text  and  PDG)  would  meet  immediately 
before  the  Addendum  3  group  at  the  same  location. 


4.  i.2.2  Redondo  Beach  Text  Meeting 

An  ad  hoc  meeting  of  several  US  experts,  including  the  NIST/NCSL 
representative,  was  held  December  1-2,  1988  in  Redondo  Beach,  CA. 
The  purpose  of  the  meeting  was  to  write  a  position  paper  for  the 
upcoming  meeting  of  the  text  study  group.  This  paper  listed  all 
the  features  that  an  improved  text  model  should  have.  It  may  be 
found  in  Attachment  2  of  this  report. 
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4 . 4 . 2 . 3  Munich  Study  Group  Meeting 

The  first  set  of  study  group  meetings  was  scheduled  for  January 
16-20,  1989  in  Munich,  West  Germany.  Text  and  geometry  groups 

were  to  meet  in  parallel  during  the  first  half  of  the  week,  and 
CGM  extensions  (Addendum  3)  during  the  second  half.  Thus, 
metafile  experts  would  be  able  to  participate  in  one  of  the 
technology  meetings,  and  the  technology  specialists  would  be  able 
to  participate  in  the  CGM  extensions  meeting.  The  meetings  were 
held  as  scheduled,  despite  last  minute  attempts  of  PDG  to  move 
its  meeting  to  a  later  date.  The  NIST/NCSL  representative,  who 
is  the  leader  of  the  CGM  extensions  group,  was  unable  to  attend 
due  to  a  family  emergency.  Peter  Bono,  chair  of  X3H3,  chaired 
the  meeting  in  his  absence. 

US  input  to  the  CGM  extensions  meeting  consisted  of  a  draft  New 
Work  Item  (NWI)  proposal  and  supporting  material  for  producing  a 
Requirements  Document  (these  were  listed  as  base  documents  in  the 
meeting  call,  which  was  written  and  submitted  by  the  NIST/NCSL 
representative) .  The  supporting  requirements  material  included 
previous  CALS  requirements  studies  and  parts  of  earlier  Addendum 
3  proposals. 

The  meeting  resulted  in  the  group  endorsing  the  need  for  Addendum 
3,  and  advising  that  it  be  expedited.  A  draft  NWI  and 
Requirements  Document  were  produced  as  required  by  new  SC24 
procedures.  These  were  substantially  the  same  as  the  input 
documents  -  all  of  the  important  CALS  requirements  were  endorsed 
and  not  many  more  were  added.  Details  can  be  found  in  the 
attachments. 

Several  milestones  in  the  NWI  schedule  should  be  noted: 

1.  SC24  ballot  on  the  NWI  and  Requirements  to  complete  by  the 
June  1989  Waikoloa  meeting; 

2.  processing  results  at  that  meeting; 

3.  JTCl  ballot  to  complete  by  the  October  1989  SC24  plenary; 

4.  substantially  complete  Working  Draft  of  Addendum  3  to  be 
done  by  the  end  of  that  meeting; 

5.  final  text  for  Addendum  3  in  April  1991. 

The  minutes  of  the  Munich  meeting  are  found  in  Attachment  3  of 
this  report.  Attachment  4  contains  the  final  NWI  and 
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Requirements  Document  for  the  project.  These  were  actually 
produced  at  the  Waikoloa  meeting  in  June  89,  but  included  here 
because  they  are  so  similar  to  the  drafts  from  the  Munich  meeting 
that  the  difference  is  negligible  (there  are  a  couple  additions 
to  the  bibliography  and  a  couple  additions  to  the  list  of  liaison 
projects) . 

The  output  of  the  meeting  also  included  three  1-page  letters,  to 
the  rapporteurs  of  the  SC24/WG1  Reference  Models  group. 
Requirements  group,  and  the  rapporteur  of  SC24/WG1  himself. 
These  letters  basically  asked  the  recipients  to  carry  out  the  NWI 
processing  steps  required  under  the  new  SC24  procedures. 


4. 4. 2. 4  Milpitas  X3H3  Meeting:  Liaisons  and  Drafting 

There  was  a  scheduled  X3H3  meeting  in  Milpitas,  CA,  February  6- 
10,  1989.  The  agenda  for  CGM  work  was  mostly  devoted  to 

processing  the  comments  from  the  CGM  Addendum  1  letter  ballot 
(see  the  above  section  on  Addendum  l) .  There  was  little  tine  for 
Addendum  3  work.  However: 

o  there  were  extensive  liaison  meetings  between  CGM  people  and 
experts  from  other  technology  areas:  text,  CGI,  geometry, 
image  storage,  etc. 

o  the  NIST/NCSL  representative  leading  the  CGM  meetings  made 
interim  writing  assignments  to  the  X3H3.3  CGM  people  with 
the  goal  of  assembling  a  new  Addendum  3  baseline  document 
prior  to  the  Waikoloa  meeting. 


4. 4. 2. 5  Between  Munich  and  Waikoloa 

Many  of  the  details  of  processing  the  Addendum  3  NWI  during  this 
period  are  found  in  the  final  report  of  the  rapporteur  of  the  CGM 
Extensions  Study  Period  (the  NIST/NCSL  representative) ,  which  is 
in  Attachment  5.  To  summarize  briefly: 

1.  As  per  the  new  SC24  procedures,  the  NWI  and  Requirements 
Document  went  to  the  SC24/WG1  Reference  Model  meeting  the 
week  following  the  Munich  meeting.  No  changes  were 
requested  by  that  group. 

2.  As  per  the  new  SC24  procedures,  the  NWI  and  Requirements 
Document  went  to  the  SC24/WG1  Requirements  rapporteur  for 
their  late  February  meeting.  That  meeting  was  cancelled  and 
so  no  changes  were  requested  by  that  group. 

3.  The  SC24/WG1  group  at  its  February  meeting  endorsed  the 
Munich  results  and  asked  the  SC24  Secretariat  to  circulate 
same  immediately  for  a  SC24  NWI  ballot. 
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This  was  done,  and  the  ballot  closed  June  15,  1989. 


4  . 


In  order  to  form  the  US  position  on  this  ballot,  the  NIST/NCSL 
representative  prepared  an  X3H3  letter  ballot.  This  was  sent  to 
the  X3H3  mailer  in  early  April  for  a  30-day  ballot  period. 
Mailing  problems  with  that  X3H3  officer  resulted  in  the  ballot 
being  delayed  until  early  June.  This  was  too  late,  so  the  ballot 
was  scrapped  and  the  US  voted  "yes  without  comment"  on  the  NWI . 

In  this  period,  the  NIST/NCSL  representative  had  to  prepare  and 
circulate  the  call  for  the  next  CGM  Extensions  study  Period 
(Addendum  3  study  group)  meeting.  SC24  procedures  require  that 
this  be  done  at  least  2  months  in  advance  of  the  meeting,  which 
was  scheduled  for  Waikoloa  in  late  June. 

Finally  in  this  period,  the  NIST/NCSL  representative  coordinated 
the  assembly  of  the  Addendum  3  draft  by  X3H3.3  CGM  people.  In 
early  June  this  draft  was  mailed  to  the  international  attendees 
of  the  Waikoloa  meeting. 


4. 4. 2. 6  Waikoloa  Meeting 

The  final  scheduled  meeting  of  the  CGM  Extensions  Study  Period 
took  place  in  Waikoloa,  HI,  June  26-28,  1989.  This  was 

immediately  following  the  CGM  Addendum  1  editing  meeting.  The 
meeting  was  chaired  by  the  NIST/NCSL  representative.  The  goals 
were: 

o  process  the  results  of  the  NWI  ballot; 

o  revise  the  NWI  and  requirements  if  necessary  and  send  to  the 
SC24  Secretariat  for  immediate  JTCl  ballot  (JTCl  is  the 
parent  organization  of  SC24) ; 

o  continue  technical  work  on  the  baseline  document; 

o  begin  work  on  the  final  report  of  the  study  period. 

All  of  these  goals  were  met.  The  study  period  final  report  in 
Attachment  5  contains  details.  This  final  report  was  actually 
produced  subsequent  to  the  meeting. 

One  point  in  the  final  report  deserves  note.  It  is  clear  that 
SC24/WG3  MRG  is  facing  a  resource  crunch.  After  all  of  this  work 
to  get  the  project  through  the  ISO  procedures,  the  question  of 
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whether  ISO  has  the  resources  to  deliver  the  project  on  schedule 
must  be  seriously  looked  at.  This  will  be  determined  at  the 
October  meeting.  The  US  will  need  to  develop  a  contingency 
strategy  in  case  ISO  cannot  deliver. 


4. 4. 2. 7  Post  Haikoloa  k  ANSI  Letter  Ballot 

The  work  done  at  Waikoloa  on  the  Working  Draft  of  Addendum  3  was 
incorporated  by  the  document  editor.  This  document  is  contained 
in  Attachment  6.  In  late  July,  it  was  sent  to  the  SC24 
Secretariat  for  SC24  circulation  and  comment.  This  is  normally  a 
3-month  period,  but  early  comment  had  been  requested  so  that 
technical  work  may  take  place  at  the  SC24  plenary  15-30  October 
1989.  An  X3H3  letter  ballot  had  been  drafted  and  circulated  as 
well.  The  purpose  was  to  solicit  comments  on  the  Working  Draft 
of  Addendum  3  and  use  them  during  the  X3H3  meeting  of  September 
25-29,  1989  in  formulating  the  US  position. 

It  has  since  been  learned,  that  the  JTCl  ballot  period  had  not 
even  commenced,  although  the  Addendum  3  schedule  showed  it  being 
complete  by  the  SC24  meeting  in  October.  The  reason  for  this 
delay  is  disorganization  within  the  JTCl  Secretariat  and  lack  of 
communication  between  it  and  the  SC24  Secretariat.  The 
consequence  is  that  Addendum  3  is  still  not  an  official  ISO 
project.  Although  JTCl  approval  is  usually  considered  a 
formality  it  is  nonetheless  the  last  required  step  in  the 
process . 

It  is  also  at  the  JTCl  voting  stage  that  the  member  nations 
formally  indicate  their  levels  of  participation  and  of  resources. 
This  will  be  a  key  issue  to  the  success  of  the  project  in  SC24. 


4. 4. 2. 8  Nashua  X3H3  Meeting 

The  X3H3.3  CGM  subgroup  had  6  attendees  at  the  Nashua  meeting, 
25-29  September.  With  the  exception  of  a  two-hour  liaison 
meeting  with  3D  and  product  data  experts  to  define  a  response  to 
an  outstanding  Addendum  2  ballot,  the  entire  meeting  was  devoted 
to  processing  the  substantial  X3H3  comments  on  the  Addendum  3 
Working  Draft  (WD)  and  forming  a  US  position  for  the  ISO  comment 
period. 

The  US  position  is  contained  in  Attachment  7.  In  summary,  the  WD 
has  significant  omissions  and  in  other  respects  is  very  rough. 
This  is  to  be  expected  at  this  stage  in  the  standards  process. 
The  WD  will  require  significant  improvement,  however,  before  the 
first  official  voting  can  commence  in  ISO.  This  is  the  PDAD 
ballot.  It  is  possible  that  these  improvements  can  be  made  at 
the  SC24/WG3  meeting  in  October. 


17 


The  US  position  also  makes  clear  what  the  priorities  of  the  work 
should  be.  Private  communications  with  other  national  delegates 
indicate  the  possibility  of  other  prioritizations  which  may 
seriously  slow  the  project  (see  next  section) . 

The  key  technical  problems  can  be  briefly  summarized: 

1.  the  geometric  primitives  are  incomplete  with  respect  to  what 
was  specified  in  the  NWI  and  Requirements  documents; 

2.  the  formulation  of  some  of  the  geometric  primitives,  as  well 
as  the  image  primitives,  needs  improvement; 

3.  numerous  technical  and  editorial  details  concerning  the 
additional  attributes,  color  models,  etc  need  to  be 
corrected ; 

4.  the  improved  text  capabilities  need  a  thorough  overhaul, 
including:  clarification  of  how  external  font  resources  are 
accessed;  better  glyph  access  methods;  clarification  and 
improvement  of  font  callout  and  substitution  techniques; 
removal  of  glyph  definition  primitives  from  the  metafile. 


4. 4. 2. 9  Status  6  Renaining  Work 

It  appears  that  the  Addendum  3  project  has  been  accepted  by  ISO, 
but  the  final  round  of  balloting  in  JTCl  has  not  yet  taken  place. 
There  is  a  procedural  possibility  that  this  can  be  skipped,  that 
SC24  can  issue  a  resolution  that  this  is  a  simple  revision  of  an 
existing  standard  and  so  JTCl  (SC24's  parent  body)  need  not  vote 
on  it.  This  will  have  to  be  explored  at  the  October  SC24 
meeting. 

Although  the  formal  acceptance  seems  likely,  there  is  still 
danger  that  the  project  will  not  progress  adequately.  This  comes 
from  views  of  some  of  the  other  national  delegations  about 
metafile  extensions.  The  US  view  is  that  CGM  relates  to  other 
computer  graphics  standards,  but  relates  more  to  "current 
practice"  in  engineering,  publishing,  and  graphics  arts.  This 
means  that  users  in  these  areas  are  retro-fitting  CGM  import  and 
export  filters  to  existing  proprietary  products.  In  the  process, 
they  care  little  about  the  other  work  of  SC24;  they  just  want  to 
exchange  graphical  infonnation  between  heterogeneous  systems.  In 
other  words,  in  the  view  of  US  users.  Addendum  3  has  more  to  do 
with  IGES,  PDES  and  PostScript  than  it  does  with  GKS. 
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The  view  in  Europe  tends  to  be  less  pragmatic  and  more  academic. 
There  is  high  interest  in  Europe  in  a  new  Application  Programmer 
Interface  standard  (API)  -  a  revision  to  or  replacement  of  GKS. 
Comments  have  already  been  heard  and  seen  to  the  effect  that  the 
Addendum  3  work  must  go  no  faster  than  the  new  API  work,  that 
they  must  work  out  access  to  all  new  technology  in  compatible 
(meaning  identical,  to  the  commenters  being  referred  to)  ways. 
These  sentiments  seem  to  echo  similar  conflicts  that  occurred 
during  CGM  standardization,  and  which  slowed  the  standard  down  by 
1-2  years. 

There  are  also  indications  that  some  think  the  scarce  resources 
of  SC24/WG3  should  be  split  between  Addendum  3  and  Addendum  2 
(3D)  .  NIST/NCSL  believes  there  are  barely  sufficient  resources 
to  do  the  Addendum  3  work.  Any  attempt  to  carry  on  Addendum  2  as 
well,  without  additional  staff,  would  have  serious  impact. 

The  US  may  thus  face  an  important  and  strategic  decision  in  the 
October  SC24  meeting:  should  it  continue  to  support  the  Addendum 
3  work  as  an  ISO  project;  or  should  it  attempt  to  block  further 
ISO  work  on  metafiles  for  a  couple  of  years  and  go  back  to  ANSI 
processing?  The  latter  is  clearly  a  drastic  resort.  It  has  been 
the  US  position  that  the  work  belonged  in  ISO.  ISO  endorsed 
this,  and  the  tentative  schedule,  in  the  NWI  process.  US 
companies  definitely  will  fare  better  in  international  markets  if 
their  standards  are  international  standards.  However,  if  the 
other  ISO  member  nations  do  not  actually  have  the  will  to  follow 
through  with  the  commitment  to  constituency  and  schedule  that  was 
indicated  in  the  NWI  process,  then  the  US  must  consider 
withdrawing  the  project. 


4.4.3  Addendum  2 

Since  the  Waikoloa  meeting  a  version  of  the  Addendum  2  (the  3D 
addendum)  document  has  been  circulated  for  PDAD  ballot  within 
SC24.  The  US  had  to  respond  to  this  ballot.  So  a  second  X3H3 
letter  ballot  was  put  together  and  circulated.  This  was 
processed  at  the  September  meeting  in  Nashua. 

The  US  position  was  defined  at  the  Nashua  meeting  in  liaison  with 
PHIGS  experts  and  those  interested  in  product  data  standards 
(STEP/PDES) .  It  appears  that  the  PHIGS  extension  project  in  X3H3 
will  take  interest  in  this  project,  as  a  means  of  providing 
support  for  STEP,  and  will  help  to  define  a  useful  scope.  There 
is  the  possibility  of  additional  staff  and  help  from  the  3D 
subgroups,  in  which  case  there  could  be  sufficient  staff  to 
process  both  Addendum  3  (which  is  important  to  CALS) ,  and 
Addendum  2  (which  is  not) . 
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These  points  are  speculative,  however,  as  the  necessary 
preliminary  liaison  between  the  3D  experts  and  the  product  data 
standards  committees  has  not  yet  occurred.  Accordingly  the  US 
position  on  the  Addendum  2  PDAD  ballot  contained  four  simple 
points:  no  further  effort  should  be  expended  on  the  Addendum  2 
as  currently  specified;  the  need  for  a  3D  metafile  should  be 
defined  by  3D  experts  and  metafile  experts  in  liaison  with  TC184 
(the  ISO  committee  working  on  STEP) ;  any  resulting  metafile 
project  should  be  jointly  executed  by  3D  and  metafile  experts; 
WG3  must  have  additional  resources  to  execute  its  part  of  any 
resulting  project.  Should  a  3D  metafile  project  result,  it  is 
anticipated  that  the  3D  experts  would  principally  uefine  its 
functional  and  semantic  content,  as  well  as  its  position  in  the 
re<"erence  model,  and  metafile  experts  would  design  the  metafile 
and  write  its  encodings. 


4.4.4  Coordination  between  CGM  Addenda  and  Graphical 
Registration 

NIST/NCSL  has  been  sponsoring  registration  of  graphical  items  for 
CALS.  These  are  intended  to  provide  a  short  term  solution  to 
functions  needed  by  CALS  that  are  being  pursued  through  the 
slower  formal  standards  process  (Addendum  1  and  Addendum  3). 

Because  these  are  addressing  the  same  needs,  the  formulations  in 
Graphical  Registration  and  the  addenda  should  usually  be  very 
similar  (there  are  cases  where  the  different  mechanism  of  the  GDP 
and  ESCAPE  elements  which  are  registered  justify  some  difference 
in  formulation) . 

During  this  fiscal  year  there  has  been  frequent  liaison  between 
the  NIST/NCSL  representative  and  NIST/NCSL  to  coordinate  the 
content  of  CGM  Addendum  3  with  the  registration  proposals.  The 
results  have  been  adjustments  to  proposals  in  Registration  Batch 
2  and  Registration  Batch  3  (see  the  final  report  titled  FINAL 
REPORT,  CALS  FY89  SOW  TASK  4.3.2,  MIL-D-28003  REVISION 
RECOMMENDATIONS)  as  well  as  reformulation  of  Working  Draft 
Addendum  3  and  additional  specifications  for  the  pending  revision 
of  MIL-D-28003.  The  effect  of  the  adjustments  is  generally  a 
convergence  of  the  proposals  and  the  draft  addenda. 
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Attachment  1: 

US  Vote  and  Comments  on  CGM  Addendum  1  DAD  Ballot 
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U.S.  Comments  on  ISO  8632.1/DAD.L(CGM  Add.n 

The  U^.  disapproves  ISO  8632-1/DAO.l  with  the  foOowing  technical  comment: 


X3H3/89.37 


PIXEL  ARRAY  should  be  removed  from  CGM  Addendum  1  and  should  be 
considered  as  part  of  the  Addendum  3  project.  There  are  several  reasons:  1)  Image 
storage  and  transfer  capability  is  being  studied  for  Addendum  3  and  the  PIXEL 
ARRAY  capability  should  be  included  in  this  more  comprehensive  study;  2)  The 
currem  PIXEL  ARRAY  formulation  is  based  on  the  CGI  formulation  and  the  latter 
is  considered  unstable  at  this  point;  3)  The  current  formulation  of  PIXEL  ARRAY  is 
device  dependent  and  apparently  does  not  exist  in  the  reference  model  at  the  same 
level  as  other  CGM  elements;  its  relationship  to  the  other  elements  at  least  to 
be  more  carefully  defined  before  being  included  in  CGM 

In  addition,  we  note  the  following  inconsistancy  whh  the  2nd  DP  text  of  CGI  and  request  that  this 

mconsistancy  be  addressed  jointly  by  the  CGM  and  CGI  RGs  of  WG3: 

The  behavior  of  CLIP  RECTANGLE  under  COPY  transformation  dlSsr*  between 
the  CGI  and  CGM.  We  believe  the  CGM  specification  is  more  compatible  with  API 
standards.  We  understand  that  the  CGI  sperification  is  «rni  subject  to  fbang**-  in  th« 
area.  In  any  case,  this  must  be  resolved  between  CGI  and  CGM. 


Editorial  Comments: 

El:  The  discussion  of  the  effects  of  anisotropic  transofrmation  in  4.12.4.5  has  been  clarified  in  the 

CGI.  CGM  should  adopt  the  clarified  wording. 

E2:  SecdoB  4.12.4.4  should  point  out  that  SEGMENT  PICK  PRIORITY  has  no  graphical  effect 

and  is  available  for  application  dependent  communicatioB  between  interpreteis  and  generators.  The 
same  should  be  pointed  out  for  PICK  IDENTIFIER  in  section  4.7P. 

E3:  In  S'xtions  4.12.2  and  5.10.1.2,  PICK  IDENTIFIER  awl  ASF's  have  been  from  the 

description  of  INHERITANCE  FILTER.  CGM  is  intended  to  be  the  «»"»«» as  CGI  in  this  area. 

E4:  Page  L  sab-claase  02,  item  c)  should  be  deleted.  It  is  not  possible  to  anticipate  what  future 

standards  will  require.  In  any  case,  it  does  not  add  any  osefiil  information  to  the  standard. 

E5:  Page  4L  Table  3.L  The  entries  for  SCALING  MODE  are  wrong.  The  entire  table  should  be 

carefrilly  checked  for  correctness. 

E6:  Pages  56*57,  sub^lauses  5.42*5.42.  Reword  these  three  siU>*dauses  along  the  lines  of,  Tb*. 

COLOUR  SELECTION  MODE  may  be  changed  only  within  the  picture  description  in  category 
’basic-sutic”.  It  may  be  allowed  in  the  picutre  body  in  some  of  the  other  categories. 
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E7:  Page  SS,  sob-clause  5.4.6.  This  sentence  is  not  useful  and  should  be  deleted. 

ES:  New  sub-clause  53.15.  There  seems  to  be  a  remnant  of  an  old  version  (stacked  attribute  sets) 

indicated  here.  If  attribute  sets  are  named,  is  it  not  the  case  tb->t  the  NAMED  aOnbute  set  be  the  one 
restored,  not  the  LAST  one? 

E9:  Page  103,  new  element  defaults.  SEGMENT  DISPLAY  PRIORITY  and  SEGMENT  PICK 

PRIORITY  should  not  be  encoding  dependent,  but  rather  the  default  should  be  zero. 

ElO:  The  grammar  has  not  been  carefully  reviesved  in  the  past  and  we  request  that  a  careful 

examination  is  done  before  IS  teat  is  produced. 

Ell:  For  Note  1  under  H  6.7,  ‘action  required*  Qag  and  *Do-action*  do  not  seem  to  be  referenced 

anywhere  else  in  the  document. 

EI2:  There  is  an  inconsistancy  in  the  usage  of  phrases  "view  surface*  and  ’display  surface*.  To  be 

consistant  with  itself  and  with  CGL  the  phrase  ‘drawing  surface*  might  be  a  better  choice. 

E13:  All  references  to  a  CGM  ‘function*  should  be  replaced  by  ‘element*. 

E14:  In  the  definition  of  anisotropic  mapping,  we  suggest  replacing  *to  physical  device  units*  with 

‘distance  units  on  the  physical  drawing  surface’. 

E15:  In  the  definition  of  edge,  we  suggest  replacing  *rhe  rendering  of  the  boundary*  with  The 

rendering  of  the  perimeter*  to  avoid  confusion  about  interior  style  HOLLOW  (rendering  of  the 
boundary)  versus  EMPTY  with  edges  visible  (rendering  of  the  edges  or  perimeter). 

E16:  In  the  definition  of  isotropic  mapping,  we  suggest  replacing  ‘device  coordinates*  with  ‘distance 

on  the  drawing  surface*. 

E17:  Id  the  definxtrion  of  size  specification  mode,  we  suggest  replacing  ‘the  state  list*  with  *tbe 

Modal  State  List*.  Use  of  the  terms  'sUta  list*  and  ’current  state  Gst*  need  to  be  looked  aL  The 
concept  of  'Modal  State  List*  was  introduced  in  dause  4i22.4  More  needs  to  be  said  about  this 
concept  earlier  so  that  it  can  be  used  and  refered  to  udiere  needed.  Also,  more  could  be  said  about  the 
gener^  states  of  the  metafile  interpreter.  Table  3.1  is  great,  but  there  needs  to  be  some  more  general 
discussion. 

E18:  The  definition  of  graphic  olqect  should  be  added  to  the  definitions.  U  is  used  in  many  places, 

e.g.  the  object  dipping  mode  concepts.  Also,  we  suggest  using  only  the  term  ‘graphic  object*  and  not 
variations  such  as  'paphkal  objea*. 

E19;  In  clause  5.4.9,  the  parameter  should  be  called  'device  viewport  specification  mode*. 

E20:  Page  42.  snb-dause  5.1  Abbreviations.  The  meaning  td  PN  should  be: 

PN  Pick  Name  Pick  Identifier 

Realization  is  an  integer. 

Range  is  implementatkm  dependent. 

E21:  Page  12,  sub-clause  42  -  The  reference  should  be  to  sub-clause  4.4.2 
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E22:  Page  2. 6tli  paragraph.  *conpoui>d  tea';  Quutfc  *tea  that  cae&aiaa*  to  tea  that  eutf  caaum' 

(a  coispoiuul  text  striog  seed  oot  exmtaia  attribute  chaogca.  a'»  compouiui  if  it  wu  tpedikd  wuh 
multiple  tea/appead  tea  eleaeau). 

E23:  Page  4,  Section  43JJ5;  This  should  be  outed  something  other  than  '|^mo'  no*  We  suggest 

*Add.l'Static-gics.*  GKSM  should  be  reserved  for  the  audit  trail  that  tt  described  in  the  other  (GK5) 
addendum. 

£24:  Page  6,  43.43,  end  of  4.4  paragraph:  It  is  very  perhaps  inappropriate,  to  keep 

refering  to  categories  which  are  not  static  pscture-caprure  There  aren't  any  dehaed  ha  this 

addendum.  Standards  should  not  be  written  in  such  a  way  that  they  imply  or  assume  very  much  about 
future  extensions.  There  should  be  a  tiagie  paragraph  that  says  'Various  reamokms  (such  as  where 
elements  are  permitted)  are  perxnined  to  be  different  is  categories  to  be  in  future  exteauoas. 

or  in  metafiles  defined  in  other  standards  which  are  based  on  tht|  oise,'  tnd  leave  it  at  that. 

£25:  Page  7.  Section  4.4.7,  end  of  3rd  paragraph  'relative  to  the  aon-ioverted  viewporr*  does  not 

convey  the  necessary  informaiioeL  S.4.10  has  the  propr  wording  and  it  should  be  repealed  here  or 
referenced  here. 

£26:  Page  8,  paragraph  7:  Under  LOCUS  THEN  SHAPE,  it  should  •ttj*  be  ssoted  that  a  thick  line 

whose  locus  is  outside  of  the  chp  window  wiD  not  have  any  portioa  vttibk  eves  if  its  lise  width  would 
carry  some  portioa  of  the  rendering  into  the  dip  recuagfe  (same  as  LOCUS  dipping). 

£27:  Page  8,  Section  433,  paragraph  8:  *When  a  width  or  size  spedScatioe  mode  is  'scaled’,  the 

rendering  of  shape  proceeds  in  OC  space  after  the  VIXT-to-Devioe  Mapping.*  It  ia  andear  whether 
this  simply  applies  to  the  aiusotropic^mapping^asd_^wide_liaes  qoestkm,  or  whether  this  is  implying 
that  SHAPE  CUFPINC  doesn’t  work  with  scaled  specifiottion  moths.  Without  using  CCPs  pipeline, 
much  of  the  wording  is  nsdear.  SHAPE  CUPPING  cBps  the  same  regardksi  of  the  spedficauoD 
mode  (that  the  whole  poist),  and  the  winding  amply  needs  to  be  dariGed 

£28:  Page  13,  Section  4.12.43,  4(h  paragraph  from  the  booon,  last  scateacr.-  Sisce  the  segment 

transformation  is  VDC->VDC,  the  VCD->DC  oupping  (itf  op  by  VDC  EXTENT  and  DEVICE 
VIEWPORT  etc.)  is  applied  afterwards.  The  last  scatfeace  of  this  paragraph  could  be  read  as  meaning 
that  the  latter  transfonnation  ia  ooiy  applied  if  the  SEGMENT  TRANSFORMATION  was  sex 
applied.  We  think  the  work  'ooi/'  is  needed  after  the  word  'using.' 

£29:  Section  433.4  and  4333  refer  to  *0X3*.  Please  chai^  this  to  the  IS  #-year*  form  ai 

reference. 

£30:  4.123.L  ’Each  segment  has  a  tmique  ideatiSer.’  This  is  sot  exactly  what  a  aaended.  We 

advocate  *No  two  global  segmesu  may  have  the  smne  identifier  asd  no  local  segmeou  may  have  an 
■dentifier  the  smne  as  ocher  hwal  sqpment  in  the  same  pkxore  or  the  tame  as  a  global  segmeat.* 

£31:  4.1233.  This  danse  does  not  actually  state  how  a  segment  is  opened.  More  fcserally,  it 

seems  sloppy  to  use  the  GKS  words  of 'OPEN*  asd  *CLOSED*  to  refer  to  static  pictore  capture  CGM 
files.  It  seems  more  natural  to  me  terms  like  'eJemenu  delimited  by  a  BEGIN  SEGMEOT  element 
and  an  END  SEGMENT  element*  when  talking  dwut  CGMs. 

£32;  Defining  a  local  segment  in  a  picture  automatically  imdudes  that  segment  in  the  picture's 
image.  This  needs  clarification. 


25 


E33:  What  are  the  highlightings  pick  priority,  aod  display  priotity  for  primitives  outside  segmenu? 

Tllis  needs 

E34:  S.10.L2, 6th  line.  To  what  does  *(see  below)*  refer? 

E35:  Under  Tage  6  clause  3*  olqect  cllppL  3  mode  needs  to  specify  what  *LOCUS*  and  *SHAPE' 

dipping  imply  and  how  they  differ.  'LOCUS  THEN  SHAPE*  ai^iean  to  be  the  logical  concatenation 
of  the  other  two  modes.  Also,  the  definition  of  'global  segments*  should  read  *these  are  segments 
adiicfa^.* 

E36:  Page  10,  sob-dause  43  Note.  Use  'within  the  definition  of  a  global  sapient*  rather  than  the 

present  *when' construction. 

E37:  Last  addition  to  Page  10,  snbdause  43:  Ftnish  first  sentence  with  *m  a  metafile  of  any 

category  <Hher  than-' 

E38:  Clause  43.4.1  should  re-iterate  that  only  a  metafile  of  category  *basic*static*  is  premitted  to 

mnit  the  metafile  category  element  as  impied  by  the  first  paragraph  of  Addendum  I,  pa^  3  (sub-clause 
43). 

E39:  Qause  4.4  first  paragraph:  Strike  the  last  sentence  or  rephrase.  ^^11  IS  863i21  s 

(regardless  of  Adxlenda  work)  are  static  picture-caixure  metaiileat. 

E40:  Page  14,  4.4.7  rephrase,  since  no  CGM  categories  may  be  other  than  static  picture-capture 

metafiles.  See  also  item  7. 

E41:  Page  14, 4.43  same  as  9  above.  See  also  item  7. 

E42:  Page  15,  sid>-dause  433,  3rd  paragraph  does  not  adequately  explain  the  difference  between 

TjOCUS*  and  •SHAPE’. 

E43:  Page  15,  sob-dause  433,  paragraph  7  does  not  adequately  explain  how  *LC>CUS  THEN 

SHAPE*  may  produce  any  difference  from  *SHAPE*  alnncT 

E44;  Page  15  sob-dause  4j6  There  are  several  lists  in  the  snb-dause.  To  which  aae(s)  should  the 
element  be  added? 

E4S:  Page  20,  433.L  The  phrase  *A  dosed  figure  is  opened.  *  is  worded  too  much  tike  segments. 

Use  ’started'  rather  than  'opened*.  Likewise,  use  finished*  rather  than  'dosed*  for  £NO  FIGURE. 

E46:  Page  20,  4j633  •  State  explicitly  whether  the  segnence  *New  Region;  End  Figure*  is  valid. 

E47:  Page  40, 4.123.1  Provide  a  reference  to  4.123  for  behavior  of  COPY  SEGMENT. 

E4S:  Page  50  subdause  53.11  ■  The  existing  shorthand  names  do  not  indude  hyphens,  even  for 

multiple  word  names.  Should  the  addendum  have  them? 

E49:  Page  SS^  sub-dause  5.4.6  -  dimitate  the  ’double  negative*  for  darity. 

ESO:  Section  4.1233.  Here  and  elsewhere,  references  are  made  to  CGM  states  not  induded  in 

Table  3.1.  In  particular,  this  sections  mentions  state  GSD  which  is  not  in  Table  3.L 
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E51:  4.12X2  The  U."  sentence  in  this  section  implies  that  only  the  stated  eiemen'  are 

allowed  in  the  This  is  clearly  not  the  case. 

E52:  Section  4.12.5  In  the  example,  the  multiple  sntribute  changes  described  by  the  right  column 

for  a  COPY  SEGMENT  (2)  instance  should  be  more  explicitly  mapped  to  actions  which  are 
tiiUng  place.  More  explanation  is  needed  to  dearly  illustrate  which  actions  in  the  segment  being 
copied  actually  cause  the  change  of  state. 
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The  U^.  disapproves  ISO  8632-2/DAD. 1  with  the  following  technical  comment* 

The  technical  changes  to  ISO  8632-1/DAD.l  must  be  reOected  in  this  part . 

Editorial  Comments: 

None. 


U.S.  Comments  on  ISO  8632-3 /DAD.  1 


The  U.S.  disapproves  ISO  8632-3/DAD.l  with  the  following  technical 

The  technical  changes  to  ISO  8632-1/DAD.l  must  be  reflected  in  this  part . 

In  addition,  we  note  the  following  inconsistancy  with  the  with  the  proposed  binary  of  CGI  and 

request  that  this  inconsistancy  be  addressed  jointly  by  the  CGM  and  CGI  RGs  of  WG3: 

CGM  and  CGI  ^re  inconsistant  in  the  specification  of  precision  of  integers 

representing  the  data  types  SN,  PN,  and  ASN.  The  CGI  spedfitadon  uses 

16-bit  integers,  which  limits  each  of  SN,  PN  and  aSN  to  64K  unique  identifiers. 

CGM  uses  integers  subject  ot  integer  precision. 


Editorial  Comment: 

Clause  7.10,  COPY  SEGMENT.  The  enumerated  values  do  not  follow  the  null-value 
rule  that  is  used  in  CGM.  They  should  be: 

0:  no 

1:  yes. 

Page  17,  new  item  h).  Why  is  metric  scale  faaor  allowed  to  use  format  real 
when  ^galing  mode  is  not?  The  text  should  highlight  this  difference. 
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UtS.  CoF^gnts  on  KQ,.8^32=4/daD.I 


The  U^.  disapproves  ISO  8632-4/DAD.l  with  the  following  technical  comment: 

The  technical  changes  to  ISO  8632-1/DAD.l  must  be  reflected  in  this  part . 


Editorial  Comments: 

None. 
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Attachment  2: 

US  contribution  to  the  Improved  Graphical  Text  Model 
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2  December  1988 

US  Contribution  to  the  improved  Graphical  Text  Model  Study 

This  is  a  US  contribution  to  the  first  meeting  of  the  SC24  Study  Group  on 
an  Improved  Graphical  Text  Model.  This  contribution  is  divided  into  several 
parts.  These  are: 

1)  Interpretations  and  Clarifications  of  the  T'jrms  of  Reference  (SC24 
N172). 

2)  Goals  for  the  Improved  Graphical  Text  Model. 

3)  Requirements  for  an  Improved  Graphical  Text  Model. 

4)  Supporting  material. 

5}  Identified  Issues. 

Several  annexes  provide  input  documents  that  may  be  difficult  to  obtain 
otherwise.  These  are: 

Annex  1.  SCia/WG1  N616  User  Requirements  for  TCSS  (DSSSL)  and  TPM 
(SPOL) 

Annex  2.  ISO  DIS  9541 ,  Parts  1-6,  Font  and  character  information 
interchange,  6  June  1988. 

Annex  3.  ISO  DIS  10036,  Procedures  for  registration  of  glyph  and  glyph 
collection  identifiers 

Annex  4.  Examples  of  ’registered"  glyphs  and  commercial  'fonts’ 

Annex  5.  Xerox  Interpress  Bectronic  Printing  Standard,  Version  3.0,  Xerox 
Corporation,  Stanford,  CT,  December  1985. 

Annex  6.  SC18AVG8  N715  Standard  Page  Description  Language,  Working 
Draft  4,  December  1988. 
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We  interpret  the  lirst  paragraph  af  N172  this  way: 

Conduct  a  study  to  deveiop  an  Improved  Graphical  Text  Model  that  will 
meet  the  graphical  text  requirements  of  a  wide  range  of  applications 
inciuding,  but  not  limited  to: 

•  Office  document  creation,  printing  and  exchange; 

•  The  creation,  printing  and  exchange  of  published  documents: 

-  Technical  drawing  and  illustration  creation,  printing  and  exchange; 

‘  Graphics  arts  and  presentation  graphics:  ana 

-  Presentation  entities  within  product  data. 

Furthermore,  this  study  should  consider  the  requirements  for  Interworking 
between  Implementations  of  graphics  standards  and  standards  in  other 
areas.  As  far  as  text  Is  concerned,  these  other  areas  Include,  but  are  not 
limited  to: 

•  Oince  and  publishing  systems, 

•  External  representation  of  product  definition  data,  and 

•  Open  systems. 

We  suggest  that  the  list  of  documents  given  in  N172  be  clarified  as 
follows: 

1)  in  the  area  of  current  computer  graphics  practice,  the  fotlowing 
document  describing  the  ’Hershey  Fonts*  should  be  considered; 

•  Hershey,  Alan,  A  Coniributlon  to  Computer  Typesetting  Techniques, 
NBS  Special  Publication  424,  April  1976. 

2)  In  the  area  of  related  SCI 8  work,  the  material  in  Annexes  2,  3,  4  and  6 
should  be  considered,  as  well  as  the  ODA/OOIF  Draft  International 
Standard  (OIS  8613).  especially  Part  6,  Character  Content  Architecture. 

3)  In  the  area  of  available  descriptions  of  commercial  systems,  the 
material  in  Annex  5  on  the  Xerox  Interpress  ‘system  integration  standard” 
and  the  foilowing  published  (and  widely  available)  documents  should  be 
considered: 

•  Adobe  Systems  Incorporated,  PostScript  Language  Reference  Manual, 
Addison>Wesiey  Publishing  Co,  Reading,  MA,  July  1985. 

-  Adobe  Systems  Incorporated,  PostScript  Language  Reference 
Tutorial  and  Cookbook,  Addison* Wesley  Publishing  Company,  Reading 
MA,  December  1985. 

-  Harrington,  Steven  J.  and  Robert  R.  Buckley,  Interpress:  The  Source 
Book,  Brady,  New  York,  NY,  1988. 

-  Knuth,  Donald  E.,  Computers  S  Typesetting,  Volumes  A*E,  Addison 
Wesley,  Reading  MA,  1986 
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-  Karow,  Peter,  Digital  Formats  for  Typafacas,  URW  Verlao,  Germany, 
1^87. 

The  SCI 8  user  r^uirements  documents  in  SC24/WG1  N7  are  out  of  date. 
The  updated  versions  In  Annex  1  should  be  substituted. 

The  last  paragraph  of  N172  discusses  schedules.  The  US  notes  that  only 
one  meeting  of  this  study  group  is  listed  in  the  resolutions  of  the  last 
SC24  plenary,  while  the  terms  of  reference  calls  for  3-4  meetings.  To 
accomplish  tne  work  assigned  to  this  study  group  the  US  believes  Uiat  a 
total  of  3  meetings  is  needed.  The  additional  two  meetings  might  be 
scheduled  as  follows: 

-  a  meeting  In  conjunction  with  the  April  1989  meetings  of  the 
Product  Data  Geometry  and  CGM  extensions  study  groups;  or 

-  a  meeting  in  late  July  1969  in  conjunction  with  Reference  Model 
Rapporteur  group  or  early  August  1989  in  conjunction  with  the  New 
API  study  group. 

The  US  interprets  the  dates  given  In  N172  for  output  document  availability 
as  requiring  that  the  output  documents  produced  by  the  study  group  be 
circulated  to  SC24  for  review  prior  to  the  October  1989  SC24  meetings. 

2.  Goals  for  the  Improved  Graphical  Text  Model. 

1)  The  model  should  support  Uie  identification  and  specification  of 
Important  attributes  of  fonts,  characters  and  text  for  the  purposes  of: 

a)  font  selection  and  substitution,  and 

b)  text  rendering  accuracy. 

as  further  described  in  Clause  4. 

2)  Fallback  guidelines  for  font  selection  should  be  possible. 

3)  The  model  should  accomodate  all  information  In  DiS  9541.  Individual 
standards  based  on  the  model  may  adopt  only  appropriate  parts  of  OIS 


4)  The  model  should  have  as  much  compatibility  as  possible  with  the 
existing  text  model  used  in  current  computer  graphics  standards  without 
compromising  OIS  9541  compatibility. 

5)  The  model  should  distinguish  between  different  types  of  attributes.  At 
least  three  categories  appear  useful: 
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font  attributes, 

character  display  attributes,  and 
text  string  attributes. 


6)  Clients  of  the  new  model  must  have  a  way  to  determine  the  extent  of 
text  objects  at  the  time  that  such  objects  are  defined. 

7)  The  model  must  be  available  for  the  next  generation  of  standards. 


36 


8)  The  model  must  be  available  lor  use  in  CGM  Addendum  3. 

9)  A  description  of  the  model  at  an  appropriate  level  ol  abstraction  should 
be  merged  with  the  SC24  Reference  Model  work. 

10)  The  model  should  support  the  development  of  standards  for  all  uses  of 
computer  graphics.  Such  uses  include  graphics  arts,  publishing,  and 
pre-press  systems,  as  well  as  traditional  business  graphics.  CAO/CAM 
and  other  scientific,  technical,  and  mathematical  applications. 

11)  There  should  be  a  single  unified  model  for  our  entire  family  of  SC24 
standards.  The  model  should  also  support  the  needs  of  all  application 
areas  that  incorporate  computer  graphics.  Graphical  text  within 
individual  standards  should  be  based  on,  but  need  not  include  all  of,  the 
model. 

3.  Requirements  for  an  Improved  Graphical  Text  Model. 

Future  API  and  metafile  standards  have  the  following  requirements  which 
the  Improved  Text  Model  must  support: 

1 )  It  should  be  possible  to  have  text  objects  whose  text  extent  is 
workstation  independent.  (See  subclause  4.2  for  additional  details.) 

2)  It  should  be  possible  to  determine  the  extent  of  a  text  object  at  the 
time  it  Is  defined. 

3)  Attribute  changes  within  text  objects  should  be  allowed.  For  example, 
it  should  be  possible  to  underline  part  of  a  text  string.  (See  clause  4.1  for 
additional  details.) 

4)  The  model  should  allow  exact  font  selection  by  standard  (registered) 
font  names. 

5)  The  model  should  support  additional  attributes  and  characteristics, 
including: 

a)  scoring  (e  g.,  underline,  overstrike); 

b)  kerning  control; 

c)  weight  (e  g.,  bold,  medium,  light); 
di  posture  (e  g.,  italic); 

e)  subscripting/superscripting; 

f|  typeface  design  classification  (e.g.,  serif,  sans-serif,  Latin); 
g)  font  family  (e  g..  Times,  Garamond,  Helvetica);  and 
n)  others,  the  need  for  which  may  be  determined  in  the  future. 

6)  The  model  should  allow  the  construction  of  complex  compound  objects, 
such  as  those  required  lor  mathematical  equations. 

7)  The  model  should  allow  shielding/clipping  to  text  images 

8)  The  model  should  support  30  text  and  fonts. 

9)  The  model  should  support  multi-line  text  (for  example,  by  defining  the 
interaction  of  control  characters  with  the  text  model.) 

10)  The  model  should  allow  explicit  control  over  width  as  well  as  height 
of  text.  (See  clause  4  for  additional  details.) 
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11)  The  model  should  allow  standards  to  provide  successive  le.eis  of 
complexity  in  their  text  models.  These  are  needed  to  enable  simple  things 
to  be  done  easily  while  giving  advanced  applications  access  to  more 
powerful  features.  The  current  single-level  model  is  too  complex  for  some 
and  too  simple  for  others. 

1  2)  The  model  should  allow  the  layout  of  text  along  arbitrary  paths 

13)  The  model  should  allow  automatic  font  substitution. 

14)  The  model  should  allow  application-definable  glyphs. 

15)  The  model  should  allow  access  to  font  metric  information: 

a)  average  or  global  metrics,  and 

b)  metrics  for  each  characte''. 

16)  The  model  should  allow  the  specification  and  application  of 
user-defined  transformations  at  various  points  in  the  transformation  of 
text  and  characters. 


4.  Supporting  material. 

4.1  Attribute  changes  within  text  objects 

It  should  be  possible  to  construct  a  single  text  object  that  consists  of 
parts  with  different  attributes.  In  .existing  API  standards  this  can  only  be 
accomplished  by  interspersing  different  output  primitives,  such  as  Text 
and  Append  Text,  with  attribute  change  elements.  This  makes  it  difficult 
to  edit  ^compound  text  objects*  and  to  identify  and  control  the  impacts  of 
change"  to  edited  structure  elements.  It  may  be  appropriate  to  provide 
this  functionality  within  the  context  of  a  more  comprehensive  object 
definition  facility.  (See  subclause  4.5  for  further  information.) 

4.2  Workstation  independent  extent  for  text  primitives 

The  association  of  font  indices  to  fonts  and  the  realization  of  fonts  are 
workstation  dependent.  Unfortunately,  the  extent  of  text  primitives  must 
be  known  for  some  operations  performed  above  the  Workstation  Stage  of 
the  Reference  Model.  One  example  is  the  PHIGS  modelling  clip  which 
cannot  be  properly  performed  on  text  primitives  today  since  their  extents 
are  not  available  at  this  stage  of  processing.  In  metafile  standards,  blind 
interchange  of  quality  text  requires  that  generators  be  able  to  determine 
text  extent  and  rely  upon  it  being  interpreter  independent. 

4.3  Specifying  the  reiative  importance  of  attributes 

Some  applications  attach  more  importance  to  some  text  attributes  than  to 
others.  There  are  at  least  two  reasons  lor  emphasizing  some  attributes 
over  others: 

-  indicating  font  selection  and  substitution  criteria,  and 

-  specifying  control  over  the  accuracy  of  the  rendering. 
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Current  standards  provide  some  support  for  the  second  of  these  goals 
through  use  of  the  TEXT_PRECISION  attribute,  however,  no  support  is 
provided  for  font  attribute  specification  which  would  assist  m  font 
substitution  or  font  selection  by  off-line  or  downstream  text 
manipulation  and/or  generation  services  which  may  need  to  emulate  the 
requested  textual  effect  with  the  most  closefy  matching  available 
facilities. 

The  following  proposals  for  accomplishing  these  goals  are  provided  to 
initiate  discussion; 

4.3.1  Font  Attributes 

A  function  should  be  provided  which  associates  font  names  and  attributes 
with  the  font  Indices  used  during  font  selection.  This  is  analogous  to 
specifying  colours  with  colour  selection  indices.  The  function  could  also 
be  used  to  download  fonts  or  otherwise  make  them  accessible.  One  way 
this  facility  could  operate  would  be  to  specify  a  font  name  in  a  font  fable 
as  the  CGM  now  does.  The  font  name  {Times  Roman,  New  Century 
Schoolbook,  etc.)  itself  Implicitly  define  a  set  of  font  attributes  whicn 
could  be  used  as  substitution  criteria  if  the  requested  font  name  is  not 
available.  Such  a  font  table  would  be  workstation  and  device  independent 
since  it  only  depends  on  information  about  fonts  whose  characteristics 
are  independently  known. 

Automatic  font  substitution  has  implications  for  both  font  resources  and 
the  font  selection  process: 

-  adequate  descriptive  information  in  the  font  resource;  and 

-  mecnanisms  to  allow  applications  to  specify  allowable  variations 
on  a  font  request  or  to  specify  requests  with  varying  degrees  of 
precision. 

For  example  an  application  program  that  is  attempting  to  do  automatic 
font  substitution  must  have  access  to  enough  information  from  font 
resources  to  enable  it  to  determine  the  characteristics  of  available  fonts 
and  compute  appropriate  'best-approximations.'  Such  approximation 
algorithms  will  vary  from  application  to  application. 

Furthermore,  application  programs  and  metafiles  need  ways  to  explain  the 
user’s  intent  and  desires  where  font  substitution  might  be  performed.  For 
example,  a  user  may  desire  only  a  specific  named  font  {e  g.,  ITC  Bookman), 
may  be  willing  to  settle  for  'similiar^  fonts  when  the  requested  one  is  not 
available  (e.g.,  use  Adobe  System’s  version  of  Allied  Corporation’s  Palatino 
if  available;  if  not,  substitute  Adobe’s  version  of  ITC  Times-Roman;  if 
that  isn’t  available,  the  use  any  modern  serif  font;  if  there  are  no  serif 
fonts  available,  then  use  any  modern  font;  otherwise...)  The  depth  of  the 
substitution  list  should  not  be  restricted  by  the  model. 

4.3.2  Rendering  Accuracy 

The  current  Text  Precision  attribute  was  introduced  so  an  application 
could  provide  guidance  to  the  graphics  system  on  the  trade-off  between 
accurate  rendering  of  text  and  efficient  generation  of  text.  It  is 
appropriate  to  provide  such  guidance  to  the  system.  However,  the  current 
attribute  Is  inadequate  for  modern  graphics  systems  since  It  does  not 
allow  the  application  to  indicate  the  relative  importance  of  various  text 
attributes  in  achieving  its  desired  effect. 
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One  way  of  provtding  add. '.oral  cons/oi  over  rende'ing  accjfacy  miont  ce 
!o  introduce  a  technique  analogous  to  that  used  by  the  PHiGS  Eienient 
Search  function  Thus,  a  speciat  type  of  name  set  could  define  an 
association  between  text  attributes  and  names  An  application  could  then 
provide  one  such  name  sets  which  has  members  whose  associated  text 
attributes  are  to  be  accurately  rendered  Members  not  specified  ma  cate 
text  attributes  whose  values  the  system  is  allowed  to  modify  as 
necessary  for  efficiency  or  to  msu'e  text  fits  wthin  the  extent  of  tre 
text  object. 


4.4  Text-related  terminology 
4.4.1  Definitions  from  DIS  9541 

Text-related  terminology  is  evolving  rapidly  Some  traditional  names, 
such  as  character,  have  been  found  to  be  too  easily  misundersiood  and  are 
being  replaced  by  more  precise  terms,  such  as  glyph  Some  terminology  is 
motivated  by  administrative  considerations,  such  as  the  need  to  develop  a 
dear  separation  between  the  traditional  ‘codes  and  character  sets*  work 
of  SC2  and  the  ‘font*  work  of  SC18  Many  of  Ihe  definitions  in  the  DiS  text 
of  DIS  9541  (Annex  2)  were  reworked  at  a  Special  Working  Group  meeting 
held  in  London  in  September  1988  to  harmonise  the  treatment  of  fonts 
among  SC2.  SC18,  SCZt.  and  SC24  The  latest  detm  tions  are 

font:  A  collection  of  images  having  the  same  basic  design,  eg  Bookman 
Italic. 

font  family  A  set  of  fonts  of  comrnon  design,  eg  Bookman, 
glyph  collection.  An  identified  set  of  glyphs 

glyph:  An  abstract  graphical  symbol  independent  of  ar^y  actual  image. 

gfyph  image:  The  set  of  information  defining  the  image  of  a  glyph  in  a 
particular  font  resource 

glyph  shape:  The  set  of  information  in  a  glyph  representation  used  for 
defining  the  shape. 

glyph  metrics:  The  set  cf  information  in  a  glyph  representation  used  tor 
defining  the  dimensions  and  positioning  of  the  glyph  snape. 

font  resource;  A  collection  of  glyph  representations  together  with 
descriptive  information  and  font  metrics  which  are  relevant  to  the 
collection  as  a  whole. 

score:  A  line  drawn  through  a  glyph  shape  parallel  to  the  baseline  [over, 
under,  or  through  the  shape  ) 


40 


4.4.2  Definitions  from  ISO  2022 

The  loliowing  deJinilions  are  extracted  (rom  ISI  2022: 

bit  combination:  An  ordered  set  of  bits  that  represents  a  character  or  is 
used  as  part  of  the  representation  of  the  character. 

character:  A  member  of  a  set  of  elements  used  for  the  organization, 
control  or  representation  of  data. 

coded  character  set;  code:  A  set  of  unambiguous  n  ies  that  establishes 
a  character  set  and  the  one-to-one  relationship  betweeri  th  characters  of 
the  set  and  their  bit  combinations. 

4.4.3  Concerns 


The  definitions  in  subclauses  4.4.1  and  4.4.2  are  not  well  reconciled.  One 
goal  of  the  study  group  should  be  to  do  such  a  reconciliation 

4.5  relationship  of  Text  to  Other  Graphical  Primitives 

The  following  model  of  graphical  primitives  explains  the  relationship  of 
text  to  other  graphical  objects. 


Examc  ?s 


1 

Linear 

Polyline 

2 

Area 

Interior 

Edge 

3 

Volumetric 

?? 

n 

High-Order 

?? 

polyline,  arc.  ellipse,  splines, 
compound  lines 

filled  polygons,  filled  circles, 
cell  arrays,  spline  surfaces, 
compouno  areas  (such  as  triangle 
strips  and  quadrilateral  meshes) 

cylinder,  sphere,  block,  CSG. 
compound  volumes 

blinking  primitives  in  which  time 
is  the  4th  dimension 


1-n  Composite  per  prim.  markers,  text,  annotation  text. 

symbols 


In  this  context,  compound  primitives  are  primitives  which  are  composed 
of  multiple  instances  from  the  same  category.  For  example,  a  compound 
line  could  be  defined  in  terms  of  polylines  and  arc  segments  with  the 
linetype  pattern  being  applied  continuously  along  the  entire  compound 
primitive.  Similarly,  compound  areas  are  enclosed  areas  whose 
boundaries  are  defined  by  instances  of  linear  primitives.  This  would 
provide,  for  example,  easy  delinition  of  boxes  with  rounded  corners. 

Composite  primitives  are  primitives  comprised  of  examples  from  any  of 
the  categories.  For  example,  the  shape  Inforrr.alion  of  text  glyphs  could  be 
defined  in  terms  of  line,  enclosed  area,  or  compound  volume  information 
depending  on  the  needs  of  the  particular  font. 

Many  typefaces  today  are  defined  as  compound  areas  whose  interiors  are 
then  filled.  Stroke  fonts  are  defined  in  terms  of  polylines.  Similarly, 
bit-map  fonts  are  defined  in  terms  of  cell  arrays. 
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It  should  be  noted  that  the  current  Cell_Array  primitive  is  constrained  to 
have  all  cells  rendered.  More  powerful  capabilities  could  be  provided  by 
introducing  cell  array  attributes  which  would  specily  an  'auxiliary*  colour 
and  a  flag  for  Indicating  whether  "auxiliary  colour"-ed  celts  are  to  be 
rendered  or  the  background  is  to  show  throuah.  A  cell  array  can  also  be 
considered  as  a  compound  primitive  composecf  of  a  grid  of  cells  with  each 
cell  being  a  filled  polygon. 

Composite  primitives  can  be  defined  in  terms  of  primitives  from  any 
category.  Thus,  symbols  could  be  defined  hierarchically  and  user-defined 
or  system-defined  glyphs  could  reference  other  glyphs  to  produce  glyphs 
for  logos  or  mathematical  expressions. 

Graphical  transformations  apply  to  all  primitives  uniformly.  Lighting  and 
shading  information  can  be  applied  using  standard  rendering  techniques. 
Since  composite  primitives  are  composed  of  other  primitives  they  need 
not  be  excluded  from  realistic  rendering  operations. 


42 


Issue:  T4 

Should  loot  attributes  such  as  italics  be  part  o(  a  font  name,  a  toni  attribute  or 
both? 

History: 

12-02-1988,  Raised  by  U  S. 

Keywords: 

Improved  Graphical  Text  Model 
Alternatives: 

1)  part  of  a  font  name. 

2  a  font  attribute. 

3)  both. 

Arguments: 

a)  Pro1;  Alt  necessary  resources  known  before  interpretation. 

b)  Prol:  Consistent  with  typographic  usage. 

c)  Pro  2.3:  All  possible  combinations  in  a  font  name  would  soon 
become  unwieldy. 

d)  Con  3:  May  result  in  ambiguity  if  different  values  are  specified  m 
the  name  and  the  attributes. 


Issue  T5: 

Should  text  facilities  allow  access  to  attribute  groups  appropriate 
to  their  shape  defining  primitives? 

History: 

12-02-1 988,  Raised  by  U  S. 

Keywords: 

Improved  Graphical  Text  Model,  glyph  shape 
History: 

12-02-80 

Alternatives: 

1.  yes 

2.  no 

Arguments: 

a)  Pro  1:  The  possible  special  effects  in  displaying  text  would  be 
enhanced. 

b)  Pro  2:  Text  usage  is  inherently  different  from  that  of  other 
primitives. 
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Attachment  3: 

Minutes  of  the  Munich  CGM  Extension  Meeting 
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ISO/IEC  JTC1/SC24/WQ1  N. 

DatK 

.  Projaet: 

ISO/IEC 

intarnationai  Organization  for  Standardization 
Intarnationaf  Electrotechnical  Commission 


ISO/IEC  JTC1/SC24/WG1 

Computer  Graphics  Architecture 
Secretariat:  National  Computer  Graphics  Associatior 


TItit; 

Sourea: 


Minutes  of  the  Study  Period  Meeting  for 
Extensions  to  CCM  Static  Picture  Capture  Capability 
(Munich,  Jan.  1989) 

Meeting  Secretary  (a.  Mmaford) 


Status:  ^  WQ1  Output  Doeumunt 

Mumbar  Body  Position 
..  Export  Optoioa 
JL_  Rapportaur  Group  Output 

Typa:  A1  ionnodlato  Output  Documont 

A2  Oaiayad  Output  Doeumtnt 
B  National  /  &part  Contribution 
_  C  Roeant  liaison  Doeumtnt 


Distribution  Typa:  Through  WG1  Sacratarist 

_  DIraot  to  Mambara 

Tlvougb  SC  24  Saoratariat 


Data  of  Submission:  i969-oi-z7 


Keywords: 


Minutes.  CCM 


ISO/IEC  JTC1/SC24  Study  Period  Meeting  for: 
Extensions  to  CGM  Static  Picture  Capture  Capability 
18«20  January  1989  •  Munich,  F.R.  Germany 
Minutes  of  the  Meeting 


Liaison  Meeting 

The  meeting  began  with  a  joint  meeiiim  b&ween  the  CGM  group  and  the  other  groups  who 
were  meeting  during  Ae  same  week.  Tnese  groups  were  the  Product  Data  Geometry  smdy 
grot^  and  the  improved  Text  Model  study  group.  The  minutes  of  that  meeting  ate  appendec 
to  thtte  minutes. 

Participants 

The  panic^ants  in  the  CGM  meeting  were: 

Germanv;  Moeller,  Brandenburg  (till  19th  pm),  Zapomue!  (part  of  the  meeting),  Schuur  (till 
1 9th  pm) 

UK:  Mumford,  Francis,  Thomas  (part  of  the  meeting) 

USA:  Bono  (till  19th  pm).  Lans,  Stoll,  McConnell  (part  of  the  meeting) 

Apologies  were  received  from  the  Rapporteur,  Lofton  Henderson.  Peter  Bono  chaired  the 
meeting  unri!  Thursday  pm. 

Aims  of  the  Meeting 

These  were  to  follow  the  new  SC24  guidelines  (SC24/N171)  and  to  produce  a  draft 
mqui^ems  document  and  a  draft  new  work  item  for  consideration  W  WGl.  The 
Keqmierxttnts  Document  and  the  draft  New  Work  Item  will  go  to  the  itefeience  Model 
meeting  in  ^ris  die  week  afrerthismeet^  and  to  WGl  28m  in  DamistadL  Thenew 

work  requirements  of  SC24  require  an  SC24  ballot  prior  to  the  JTC1  tnUIoL 

Relevant  Documents 

SC24/N9  -  Requitements  Study 

SC24^15 .  Proposal  for  a  CGM  Addendum  3 

SC24/N52  •  An  uriritl  Draft  of  Addendum  3  produced  by  ANSI 

TC188/SC4/N284.STEP  ^ 

SC18/WG8/N715  (Rev)  -  SPDL 
SC24^177  -  S04  Proposoi  Reference  Model 

There  were  no  offidai  inputs  to  the  meeting. 
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The  Way  Forward 

II^  to  define  the  precise  net  .x  rf  Je  woik  as  it  is  so  closely  tied  in  with  the  other  sr ' d y 

to  r^rt  before  the  fi^  rcquiremems  can  be  drawn  up.  There  was 


^  puipoM  of jte  meeting  was  not  primarily  to  develop  the  Addendum  3 
wotK  based  on  mevious  drafts.  The  aims  were  far  wider  *nd  the  purpose  to  recognise 

requirements  rather  than  to  define  precisely  how  these  nri^t  be  met. 


Timescales 


uiHii <u  ujB same nme  was prereraoie to noinmg  separate 
rrSSt'S^S  regu^  the  same  experts  to  attend.  Particular  attention  was  paid  to  the 

15  March  NWI  ndloi  starts 
15  June  NWI  Ballot  (doses 

3  July  Mettinj  in  Hawaii  to  revise  NWI  -  fitxed  to  SC24 
5  July  SC24  rarwards  ballot  to  JTCl 
15  July  JTCl  ballot  starts 
15  Oct  JTQ  Ballot  ends 

Sept  90  DI&DAO  text  prepared 
April  91  IS  text  prqtared 

^  is  a  very  tight  schetWe.  It  was  amsidered  that  it  was  necessary  at  least  for  the  fim  few 
stages  to  ensure  unproved  paitidparion.  /  «  «w  *v*  u« 

Uaispn  is  i»ededbet(^  SC24  and  SC18  at  their  meeting  in  Munich  and  at  the  STBP 
meeting  in  San  Antonio.  Wc  need  an  SC24  rep  not  necessarily  a  member  body  lepiesentati 

Action  for  the  Rappoiteur  to  request  liaison  at  these  meetings  and  to  ensure  participation. 
Discussion  on  the  Requirements 

(5C34/N186)  include  the  need  for  SPDL  tp  oansliiie  a  CGM  into  SPDL  in  a  standard  way. 


VC. 
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ODA  allows  this  and  includes  CGM  in  its  spedficaiion.  Areas  of  overlap  need  to  be  solved 
in  a  common  way. 

1110X6  was  agreement  that  extensions  to  the  CGM  migto  include  puhlisbing,  engineenng 
drawing,  buiinesB  graphics  as  included  in  doc.  N9.  C^graphic  requirements  are  also 
needed.  Wtendo  we  Know  when  to  stop  adding  ftmcdon^ty?  The  leqauements  document 
muststaiedris.  r 

It  was  agreed  that  Addendum  3  (or  whatever  it  becomes)  «hnHM  not  be  3D  and  diat  it  should 
be  built  on  CGM  plus  Addendum  1.  Ihen  possibly  exte^  to  3D  for  added  capabilities. 

It  was  agreed  that  a  closed  list  of  elements  might  be  better  for  jetting  a  standardproduced 
than  less  clearly  defined  requirements.  The  precise  list  sbouk^e  agreed  when  j^  study 
penods  come  to  an  end  (October  89)  It  is  hira  diou^  with  the  w^  going  on  inraiaiki 
within  SC24  and  outside  in  other  ISO  groups.  The  sTEP  work  is  in  early  stages  (DP)  of 
standardisadon  and  their  timescale  is  1ms  agtessive. 

The  discussions  as  to  the  precise  requirements  were  based  on  a  consideration  of  N15.  6 
areas  of  extension  were  recognised: 

1.  Advanced  2D  requirements 

curves  -  ooie  STEP  line  extension  might  be  of  Interest 
fine  control  over  line  ^rpeaiance 
composite  line  primitive 

user  defined  line  types,  hatch  styles,  markers  >  also  symbols  required  widr  the  same 
definition  techniques  as  iruukexs  >  and  glyphs 

additional  standardized  hatch  styles 

arbitrary  text  path 

are  filling  methods  sufficient?  there  is  a  need  to  make  up  sQ^les  fiom 

the  other  primitives  •  note  CGI  Bitmq)  fill  too  but  this  is  not  device  indqxmdent 

general  linear  transformation  •  need  firr  3*3  matrices 

2.  Text  and  Fom  Model 

take  the  requirements  from  the  study  grotqi  on  text 

3.  Arbitrary  Boundaries 

There  was  concern  as  to  the  munber  of  stan-end  Imundaiy  sequences  there  are  in  the  doc 
NS2  (plus  closed  figures  in  Addl  and  CGI).  It  would  be  better  to  have  a  general  path  element 
which  would  then  nkve  its  action  applied  to  iL 
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4.  G}lourMcxls 


Tliis  is  definitely  a  requirement  and  close  study  is  of  the  ODA  colour  Addendum. 

Colour  inteipoladon  is  also  needed. 

5.  Image 

SC2/WG8  have  woik  in  the  area  of  compmsion  techniques.  Their  <k)cuinents  are  at  DIS 
level  and  should  be  used.  Can  ceil  array  m  improved  by  maJcing  it  more  ccunpact  in  its 
encoding 

6.  Symbols 

There  is  a  need  for  defining  symbols  and  also  for  external  referencing  *  this  is  a  general 
requirement  for  odier  areas  e.g.  fonts. 

Another  requirement  might  be  for  directories  of  pictures  to  be  stored. 

(Alignment  (N 15)  left  out  as  nobody  could  explain  it) 


There  was  some  concern  that  a  dtird  addendim  to  CGM  might  not  be  the  best  way  to 
progress  the  document.  Addexida  are  confusing,  lliis  woulo  also  be  difficult  if  there  is 
another  colour  model  as  RGB  is  described  in  many  nlaciB;.  A  revision  would  be  better  but 
this  would  have  many  implications  e.g.  doing  3D  fully. 

h  was  agreed  that  the  extensions  woik  was  to  address  storage  capabilities  at  the  same  level  of 
the  reference  model  as  CGM  and  Add  1. 


STEP/CGM  Reference  Models 

The  group  discussed  the  (fiagi^s  presented  in  N2S7  The  discussion  was  led  by  Mr 
^gmnuel  Piesenianonenuties  are  on  the  border  ofthe  CAD  system  and  the  graphics 

Some  conunents  were  made  on  the  specifics  of  the  tflagwim  CGM  and  are  not 
necessarily  at  the  right  place  relative  to  the  new  CGI  model,  the  graphics  p«pirii«p  ran  ai<n  be 
wide  or  narrow  dqjendmg  on  the  impienrentariem  (ibo^  conceptnally  of^  layers 
may  still  exist).  It  woulobe  usefiil  to  add  the PHIGS  archive  and GKSM  in.  Itwas^reed 
that  this  was  cure  example  of  how  things  fitted  together  mthin-  than  Wig  a  definitive 
staiemenL 

T^  bell  curves  on  the  sixond  diagram  were  felt  to  be  a  useAil  leoresentBrion  of  the  tiosition 
of  the  various  standards.  McConnell  to  take  this  diagram  to  the  Reference  Model  matins 
STEP  should  end  where  CGM  starts.  STEP  and  CGM  should  replace  IGES  giving  no  ” 
werlap  between  the  standards.  There  needs  to  be  a  definition  of  tte  differences  between  a 
drawing  and  a  document. 
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Reference  Model 


Hie  Reference  ^del  draft  0N177)  wasjpresemedby  John  McConnelL  The  mop  discussed 
the  model  in  relation  to  the  CGM  and  GKSM  and  tte  f!fwmni»nrc  are  to  be  fed  oack  to  the 
Reference  Mocfel  group. 

The  CGM  is  a  single  workstation  withe  coordinates  stored  in  virtual  device  coordinates.  The 
Workstation  level  is  dius  die  most  likely  point  for  the  CGM  to  lie.  F-i«n«its  sudi  as  pixel 
array  are  probably  lower  and  dm  is  likely  to  be  a  point  of  concern  m  some  of  die  comments 
on  me  Ada  1  ballot.  If  we  are  to  .sav  diat  the  CGM  eytwwinns  are  at  die  same  level  as  CGM 
can  raster  ops  be  added  (as  currently  proposed). 

There  was  some  concern  that  the  model  could  have  multiple  coordinate  systems  at  the  same 
level  This  maic«  it  harder  to  place  CGM.  Could  CGM  m  a  list  of  elements  which  range 
across  a  number  of  levels  of  the  metafile  widi  the  Metafile  Carecory  being  used  to  Identi]^  a 
particular  sort  of  metafile  and  thus  where  it  lay  in  the  model.  1ms  is  not  m  line  widi  the  idea 
that  CGM  is  well  defined  in  the  model 

It  was  noted  that  the  CGM  extensions  woik  is  a  pan  of  die  first  generation  of  standards  and 
thus  this  model  does  not  necessarily  ^ly.  Also  thm  will  not  necessarily  be  standards  for 
all  levels. 

Disctission  on  the  Initial  Draft  (N52) 

The  document  N52  which  was  produced  by  ANSI  some  time  ago  was  discussed  widi  the 
expettt  mal^g  points  which  can  be  fed  into  (hr  next  draft  The  comments  are  appended  to 
the  minutes. 

Output  from  the  Meeting 

1  These  minutes 

Action:  Mumfbid  to  draft  and  .send  to  Bono  for  circulation 

2  Draft  Requiietnents  Document 

Acrion:  Gioupm  draft  McCoxmelJ  to  take  to  Ref  Model  meetings  and  then  to  arrange 
drcularion  in  wGI  via  Bono 

3  Draft  New  Work  Item 

Action:  Group  to  draft  McCoimell  to  take  to  Ref  Model  meetings  and  dien  to  arrange 
dreuiation  in  wGl  via  Bono 

4  Letters  from  the  Rapporteur  to  Reference  Model  and  Requirements  groups  in  WG 1 
and  to  WGI  convenor  requesting  acrion  on  (he  documents. 

Action:  Bono  to  draft  and  send  to  Henderson 
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i^.-^pciidix  1 

Comments  on  The  Initial  Draft  for  Addendum  3  (SC24/N52) 

This  was  a  very  brief  discussion  but  the  following  points  emerged: 

I .  Advanced  2D  Requirements 

a)  curves 

STEP  Geometry  has  the  following  2D  primitives  (Presentation  also  needs  to  be  checked) 

conic:  dreie,  ellipse,  hyperbola,  parabola 

bounded  curve:  polyline,  B-spline,  trimmed  curve,  composite  curve 

SPDL  must  be  checked  to  see  if  the  representation  of  the  curves  defined  in  N52  is  the  most 
effideni  for  SPDL. 

b)  line  appearance 

STEP  parameierises  the  end  point  of  die  line  which  can  be  user  definable  (4.12J5  in  STEP 
presentation) 

STEP  also  has  rounded  asymmetric  line  join.  These  considerations  also  apply  to  edges. 

c)  composite  hne  primitive 

These  was  a  general  agreement  that  the  same  method  should  be  used  for  shieldine  and 
dipping.  Too  many  begin*<md  pain  appear  in  N52.  Should  this  also  be  adoptea  for  dosed 
figure?  There  axe  mfidence  here  thou^  Need  to  look  as  SPDL  paths.  There  may  be 
conflia  widi  CGM  Addl  diough. 

d)  user  defined  line  styles  etc. 

Tlieie  was  a  feeling  that  the  needs  of  cartography  had  not  been  addressed  and  that  they  should 
be. 

e)  additional  haidi  styles 

There  is  a  need  for  styles  to  be  defined  tom  the  other  prunitives.  We  need  a  wider  caMbiliry 
for  filling  of  areas  than  just  cross  hatching.  How  should  this  be  addressed  -  what  is  a  natch ' 

f)  aibioaty  text  path 

the  begin-end  path  comments  addressed  above  apply  here  too. 

g)  filling 
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PostScript  has  the  non-zero  winding  rule  as  well  as  the  odd/evcn  filling,  (pg  71  red 
Po.stScript  book).  Inteipolated  filling  (going  fiom  one  colour  to  another)  also  seems 
importanL 

b)  general  linear  transformations 
These  are  not  in  N52  but  would  be  usefiiL 

2.  Improved  Text  and  Font 

•  ->  ■ 

Sironc  feeling  that  the  work  of  SC18  and  the  work  of  the  study  group  on  the  improved  text 
model  must  be  the  main  driving  force  for  the  dements  in  this  section. 

3 .  Qipping  and  Shielding 

What  does  text  shielding  apply  to  -  the  character  box  or  the  shape?  This  needs  to  be 
addressed  in  relation  to  the  discussions  on  glyph  dei^rion  inttie  improved  text  study  group. 

4.  Colour  Models 

Tliere  is  nothing  in  N52.  This  needs  to  be  addressed  but  it  will  be  one  of  the  hardest  things  ro 
^d  m  if  the  text  is  to  be  an  addendum.  RGB  is  mentinned  very  many  times  in  the  CGM  text. 
The  ODA  colour  model  and  PHIGS  should  be  used  as  base  documents  for  the  elements. 


5.  hnaging 

The  reference  model  makes  this  a  mblem.  How  can  the  CGMMddS  be  at  the  place  in 

the  reference  model  if  these  more  device  dependent  etoents  are  added  in?  It  was 
recommended  that  die  work  on  picture  coding  standards  in  SC2  sh™ld  be  the  hasiit  for  any 
definition.  Do  we  need  Pei  Array  Clip  Rectangle?  Does  general  citing  apply  to  raster? 
Arbitrary  dipping  of  raster  mij^t  be  useful  too. 

6.  Symbols 

Has  Add  I  dealt  with  this?  If  not,  why  not? 
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Attachment  4 : 

Addendum  3  New  Work  Item  Proposal 
Addendum  3  Requirements  Document 
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CGM  ADDENDLT^'  NEW  WORK  FHEM  PROPOSAL 


Scope 

Tlus  work  compriaes  a  set  of  elements  which  will  extend  the  of  the  CGM  <IS  8632) 

and  CGM  Addendum  1  (ISO  8632/DAO.  1)  to  meet  additional  user  rcxjuunixzits- 

The  following  list  of  capabilities  will  be  addressed  by  this  went 

1)  Advanced  2D  graphics,  to  include: 

•carves 

•fine  cOTOni  of  line  appearance 

•  composite  line  pncnhnves 

•  user  defined  line  types,  hatch  styles,  and  marker  types 

•  addidonai  standatdiasd  hatch  styles 

•  artnirary  text 

•  suing  mechanisms 

•  general  linear  mmsfannations 

2)  Improved  text  and  font  support 

3)  Arbitrary  boundaries  for  dipping  and  shielding 

4)  Additional  color  models  beyond  RGB 

5)  Addidonai  raster  graphics  (scanned  image)  capainlides 

6)  Symbols:  external  reference  m  "standard*  Ubraiies  of  namerf  symbols 

The  prsdsc  list  of  dements  to  be  induded  in  this  group  will  airy  account  of  work  of  the  SC24 
sou./  groups  in  the  following  areas:  Improved  Gr^thkal  Text  Model,  Pnxtoa  Data  Geometry, 
new  API  for  graphics,  PHIGS  BR,  Reference  Model  for  Computer  Graphics,  and  also  the  GKS 
Maintenance  wc^ 

Purpose  and  Justiflcadon 

The  purpose  of  this  work  is  to  extend  the  CGM  and  CGM  Addendum  1  » fulfill  additional  2D 
picture  storage  and  remeval  requirements.  COM  users  have  fixtod  that  in  some  arolicadon  areas 
the  present  standard  pmvi^  a  goierai  Erazrewodc  that  is  nwahu  imt  Jacks  smse  ranedoadity 
required  by  these  applkations.  these  areas  indude  eogineearing  drswing,  ihe  preparation  of  graphic 
arts  quality  presentation  materials,  cartography,  and  publishing. 

SC24  has  recogtraed  the  need  to  serve  these  aii^licahan  areas  and  to  meet  tt»  requirements  which 
go  beyond  those  conemly  specified  in  the  standards  devdonxi,  and  being  developed,  within 
SC24.  The  precise  requiremeno  wOl  be  the  result  of  the  deuboaiions  of  die  study  groups  set  up  by 
SC24  to  consider  an  Improved  Graphical  Text  Model,  Product  Data  Geometry,  ^  a  new 
Apphcaoonl^grafflminglnxerfiKe  for  Graphics.  &  is  coosidered  that  iiieedng  these  requirements 
is  essential  if  the  CGM  is  to  continue  to  be  used  in  the  areas  recognized  above. 

It  is  essentiai  that  this  work  uses  some  of  the  solutions  adopted  widun  reiatni  ISO  Sondards 
activides.  for  example  font  definition  standards,  colour  Tno^Jy  and  product  data  exchange 
standards. 
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Cooperation  and  Liaison 


Work  win  progress  within  ISO/IEC  JTC1/SC24  in  liaison  with; 

IS0/IECJTC1/SC18 

ISOTC184/SC4 

ESo/mcjTci/sa 

Relevant  Documents  to  be  Considered 


CGM.  IS  8632  (Para  1-4) 

CGM  Addendum  1.  IS  8632yDAD-l  (Pans  1-4) 

Font  and  Characaer  Infomiarion  Exchange,  ISO  DIS  9541  (Para  1-6) 
OOA,  ISO  OIS  8613  Colour  Addendum 
PHIGS  BR 

Reference  Model  for  Computer  Graphics 
STEP.  ISO  TC184/SC4/N284 


Program  ofWork 


The  following  schedule  is  proposed  for  this  work: 


Oct.  1989 
April  1990 
Sept.  1990 
Apnl  1991 


-  NWI  approved.  WD  prepared 

-  DP  or  PDAD  text  prepaid 

-  DIS  or  DAD  text  prepared 

-  final  text  prepared 


Assignment  of  Work 


SC24  requires  that  this  work  item,  if  approved,  be  assigned  to  SC24/WG3. 
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Rcquirancna  iloaimeot  for  to 

The  Computer  Graphs  Metafile 


LO  bitroducatian 

It  hM  heen  wwipiiTwl  t»  «t  Ae  cnrrent  GGM  Stovtort  ^  t>P  fm-rAM  in  order  to  efff  ihely 
fulfill  the  pictTO  stonpe  and  transfgrewireiueiiuofeHgiivjfjriiigrfTaamiyt,  aits  and 

technical  pobliafaing.  The  purpose  oftfaia  document  is  to  ideinify  the  requiieineoB  for  extenaon 
expliddy.  as  specified  by  the  procedures  stipulated  in  ISQ/IEC  JTCl  SC24  N171. 

2.0  Appilcadoos 

2J  Application  Anas  With  Further  Requirements: 

a)  Engineering  Dtawings 

The  COM.  is  cunendy  being  used  in  enpneering  applicadoos  to  anH  exchange  picture 
mfannanon.  This  area  of  use  has  found  the  OGM  lacking  in  fimctiouality  wfaidi,  if  would 

increase  the  efficiency  of  storage.  Examples  of  required  eJements  indiirfw  curve  definitions,  such  as 
B'spline  and  coni^  and  improved  toz  capahilities  in  other  areas  fnntT*  control  is  required. 
Examples  of  this  include  control  of  line  appeal  << nee  such  as  ihw  There  are  requirements 

for  specifying  and  referencing  symbols. 

b)  Graphics  Arts 

For  gtaphicaiisqnality  a  fairer  degree  of  control  over  the  rendering  of  graphical  and  text  objects 
is  required.  Line  ***">«»<  are  required  to  control  the  rendering  of  line  endings  and  line  joins  and 
user-defined  ling  types  are  also  required.  There  is  a  requirement  to  be  nHig  to  print  text  along  an 
arbitrary  path  and  to  specify  fonts  and  text  attributes  in  a  more  precise  manner.  Further  colour 
models  and  raster  encodings  are  also  required. 

c)  Technical  Publisfaing  and  ninstratioas 

One  of  the  main  uneittiotis  of  the  OGM  Standard  is  to  suppmi  the  requiit'.^i:.!.'  of  tfn*  applicaiico 
area.  Though  the  OGM  has  been  used  saccessfhlly  in  the  tgrtnitmi  Twhiijthing  and  Qltistruion 
environment,  it  is  frit  that  some  of  the  inhereut  llmuations  in  the  CuM  Standard  have  rai»t«ii»yi  its 
acceptance  in  the  Seveal  to  the  CGM  have  iyie«  iHgntifigd  to 

these  limitarioiis,  including  but  not  lirniBiti  tex  Sue  app^Ji'Jitn*  control,  arbitrary  text  paih,  mhann^ 
text  capabilides,  and  addirtonal  odour  models. 

22  Studies  of  Application  Requirements 

a)  Produa  Data  Geometry  Study  Grotqi  Rqxn  •  roc  SG 

The  purpose  of  this  study  group  is  to  look  at  the  relatiaosfaips  between  Product  Data  Geometry 
(PDG)  and  Compiiier  Graphics;  its  memfaerifaq)  be  drawn  fiom  ejiperts  fiom  the  Cooeputer 
Graphics  Staadimi  and  PmAia  Data  Gaomeny  enwiimniiiif^n  discussing  these 

rebuxonsfaips  at  the  first  iiirrring  in  Mraricfa,  it  was  found  that  there  exisa  some  overiap  between  dte 
stated  gtrals  nf  the  FDG  SlandairiS  and  the  OGM.  The  Sn  ennrinrfwri  in  ceftain  are**  rim  fyjM, 

if  extended,  could  be  uriBsed  tri  fblfill  those  goall.  Some  ef  tfae  mqui]pwnen«  fnr  eartendfm 
included  ccanpleT  cnives,  addinoaal  user-deoneafale  attributes,  wMitinnai  foot/text  fnnctumaliiy, 
and  symbol  litnries. 

b)  Text  Study  Group  Repen  -  Text  SG 

Given  that  SC24  has  recognized  that  the  current  text  ninH^i  needs  review,  th**  study  group  has 
been  chartered  to  look  at  what  enhancemena  are  necessary  and/or  riewT**!  for  the  existing  gtaphicai 
text  models.  The  main  conclusion  of  this  SG  at  the  Munich  meeting  was  the  Font  Standard 

work  taking  place  in  SCI  8/WG8  should  be  the  primary  soioce  of  technical  input  for  improving  the 
graphical  text  model.  The  SG  also  uncovered  some  addidonal  requimnenu  for  text  in  studying  the 
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STPP  qatiriattL  nf  the  i^haiirMnenB  iH«.wi4«»«4  rr!X4  {nrtwWl  foHt  riffiniOtMl  afld 

refeieadng;  fan  safastgapon.  aod  lendcrhig. 

c)  CGM  ia  the  Reai  Worid  Wodcsbop  •  CRWW 

TW«  Wtyfaehnp,  iiivntvingiinplaneaggaiaftfaeQGM.mttmSmttBaberof  1987  lo  discuss  die 
fnnrmit  and  encanmered  itmlewientinj  th*.  Rttndml  At  dds  ^wricsiwp. 

seveni  common  probfansmdstoiaaiuugsofdieOGM  woe  ideorified.  Some  of  these  included, 
hot  were  not  fimim  to:  the  inadeqoacy  of  the  ten  model,  the  lick  of  advanced  2'D  graphics 

prinnnves,  and  the  need  for  addirinnal  oototir  models. 

d)  User  Requirements  Stndy  of  Publishing  and  Technical  Dnwings  -  WGl  N9 

This  report  was  produced  under  the  ansmces  of  the  U^.DoD  Computer’ Aided  AoquisinOT 

Sqipon  (CALS)  QfiEoe.  CALS  is  armqorinitiative intended  to  automate  the  production, 

exchange  and  pnblihhing  of  piodna  snoport  infonnadoo.  ftoihict  soppon  infonnadoo  in  CALS 

includes  prodnct  data,  raster  graphics.  technical  dnwdngs  and  teaa.  Tins  study  (WGl  N9) 

q>wtfiret»y  wMTBMeadieractenaonieqoiieinentsfertheOCatiosnppoattfaetecfaTiicalillumaiion 
jmrfqnrage  needs  fig  CALS.  Several  needed  enhinermmts  are  ideodfied.  including 
bezier  curves,  line  cap  and  join,  enhanced  text,  shklding;  interpolated  fOL  and  additional  colour 

models. 


e)  Input  into  the  GKS  Review  •  Canograpfaic  Requnemeaxs  (GR) 

This  Htyaimwit  is  a  tequhoxients  satemeot  Dut  together  by  expens  fiomtfae  cartographic  industry 
legaiding  the  enhanconeats  needed  to  GKS  to  suppoRcartopapbic  arolicanons.  These 
enfaancenaents  are  also  required  for  the  CGM,  and  mdude:  geoinenicaUy  qiecafied  patterns, 

arbitrary  clipping  regions,  and  external  symbol  Uhcazies. 


XO  Required  Capabilities 

The  following  table  provides  a  list  of  the  features  that  were  identified  as  requhements  in  the  snidies 
in  Section  2.  The  fiatozes  are  listed  akmg  with  the  smdy  fiom  vdiich  they  ocigitiated: 


—FEATURE— 
Advanced  2-D  giapfaics: 


•curves 

-  line  appearance  control 

•  composiie  line  primidves 

-  user-defined  liDe,hatchjoarker  types 

.  ■ri(4irinn»l  ^t^wtarrHagd  hatch  Styles 
-athitrazy  text  path  _ 

-  geoineizically  specified  patterns 

•  general  tzansftarmanoos 


—REQUIREMENT  SOURCE— 

PDG  SG.  CRWW,  WGl  N9,  Text  SG 

PDG  SG,  CRWW,  WGl  N9 

WGl  N9,  CRWW 

WGl  N9,  PDG  Sa  CRWW 

WG1N9,FDGSG 

PDG  SG,  Text  SG,  WGl  N9 

PDGSG,CR 

PDGSG 


P^hanfyri  Watt  mud  fhnt  capihililifts: 

•  fbnt(giyph  definition 

•  fiint  rtf erencing  and  snbsdtunon 
-rendering 

-additional  text  amibntes 


Text  SG,  PDG  SG.  CRWW  WGl  N9 
see  above 
see  above 
see  above 


Arbiir^  boundaries: 
•clipping 
-  shielding 


WGl  N9,  <31.  CRWW 
PDG  SG,  WGl  N9 


WGl  N9,  CRWW 
WGl  N9 


Cblour  models: 

-  (3E.  CMYB,  named  colours,  etc. 

-  inteqioiated 
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WG1N9 


Adttirinrat  iiger  gffpfaics: 

.  ccxiiag^coanwginn  tediniqties 

Symbols: 

•  exteasl  lib.  WG1N9.F1XjSG,CR 

•  use,  iwwfnal  lih.  SBesbove 

4.0Ezam|)Ies 

4J.  AdutawedlD  Graphics 

The  CGM  in  tfae  Real  Worid  Woiksfac^  examined  the  issue  (^'advanced  2D  ^incs  aod 
nrwirliiHffj  ftmf  I'YTM  eajwMhtiea  tn  rfTwjiii^ly  aAiwimd  nief  niwis.  For 

example,  ftr  mgineermg  dnsnnB  it  is  difidcnli,  if  not  inqnssible,  ID  eflectivdy  lepteseot  some 

higher-  level  coostinctsln  the  CGM.  snch  as  ispHnes  and  corves.  Thon^  sacb  coosmxxs  can  be 
«mmlatMiiTtfititwpWTWTiingvgs  in  the  CGM.it  is  ftBqnewdyimpfwriWgtnfTMTTiiainacagacv  and 
visiul  cooiiin^  and  stm  letain  device  independence.  A  list  of  addidonal  fimctknal  reqnsemems 
for  advanced  2D  eaoimplee  of  the  twItMtifi  mtpiiiwnents: 

a)  Curves 

Curves  »nrinrf>»  tfae  general  class  of  carved  line  dements  that  are  more  complex  than  the  existing 
t^iirniar  anrf  ^tptieal  arc  clenients,  snch  as: 


•  Bezier  corves 

.  Rational  B*splines 

•  Panmesic  ^line  carves 

•  Conics,  and  conic  arcs 

b)  Hue  Control  of  Line  ^ipcarance 

This  tfae  ackfatianal  line  annbutes  of  cap,  tniire,  and  joiiL 

c)  Coinposue  Line  Mmisve 

Tfaiscoiisistsaf  alineconqmsedof  both  strain  and  curved  line  segments. 

d)  User  Defined  line  Types,  Hatch  Styles,  and  Marker  Types 

An  example  would  be  the  ability  to  define  a  line  ty^  socfa  as  tfae  sdtched,  center,  or  phantom  line 
types  frequendy  used  by  engineering  drawing  applications 

e)  Arbitrary  Text  Path 

Text  drawn  along  a  cooqtositB  line  path. 

f)  HUing  Mtt±anisna 

Interpolated  FilL  wfaidi  is  a  fin  oompiised  of  colours  intexpolaied  linearly  between  two  reference 

coloun. 

g)  General  Linear  Ttansfbnnanons 

3  X  3  (and  2  X  3)  ttaruformaiion  matrices  to  allow  for  affine  arid  projective  transfotmatioos 

42  Enhanced  Text  and  Foot  Capahiliries 

The  enhancH  text  atxl  font  capabiHdes  should  accomodate  most  of  the  infixmatiaa  in  the  ISO  DIS 
9541  Font  arid  Charaoer  lofornuuion  Interchange  Standard.  This  standard  defines  a  font  resource 
aichiteatrre  to  suppon  text  genennon,  interchange  arxl  presentation.  A  font  resotnce  has  to  provide 
sufficient  information  to  characterize  and  identify  a  font  in  order  to  allow  font  referencing  and  font 
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tnhitntimnw  fp  rfift  latter  easft.  mectonisiM  to  alltwhU  ■wriOTona  on  a  fo«  request  OT 

requests  wiifa  varying  degrees  of  pmasion  should  be  provided. 

Foot  and  gfyph  desBnidon  reqmies  andbntes  in  addhkxi  to  those  nsod  in  die  coixent  ooasjoiBr 

jfflphirf  MW  |wrv<«»i,  such  as  type£ree  design  posnne,  »nd  conttoL  However, 

to  support  features  snch  as  aitdoaiy  text  path,  infonnatum  cnnentiy  not  in  ISO  DIS  954 1 

would  have  to  be  provided. 

Techniques  used  in  gia^)hics  systems  be  provided  to  thi»  juusipretff  of  a 

frp  the  desiiedrendaing  accuracy  tniwttirat^rtw  in  nMMunee  of  various  text 

aniiboies  for  achieving  a  desired  effect. 

SLO  Constraints 

The  wotk  which  is  proposed  to  meet  these  reqdremetmwil!  be  based  on  the  COM  standard  and 
CGMAddendom  l.Itis  intended  that  dnsextensian  win  occupy  the  same  point  in  the  SC24 
Reference  Model  as  the  standard.  Hus  that  the  wrwwmnw  wiu  prodnee  a  metafile 

snitafale  for  the  and  retiieval  of  2-^  picoire  infruuntnw^  ami  wiQ  not  address  3*D  or 

dynamic  capabilities,  n  is  the  goal  of  this  wariedutt  it  win  be  useable  by  rdtted  standards  including 

the  font  wnrfafirHT«rifin  effort,  OOA,  and  STEP. 


Qrtjte  woddng  with  the  GKS  Maintenance  group  is  Where  this  group  defines 

ftwirtinnaKfy  qthiefa  is  the  same  as  that  proposed  fir  riiia  iiwwtriiiri  wA,  ifaen  the  groops 

should  woric  together  to  produce  fimcdanally  ideoded  spedfiotiians  and  encotfings.  The  progress 
of  this  walk  win  be  meamred  by  its  reladonsfa^  to  these  other  standards  and  their  lesnlting 


companhiliry. 


The  New  Wodt  Hem  pitmsal  (kfises  the  areas  of  extension  and  notes  foe  need  to  adopt  the  results 
of  the  study  groiqis  of  SC24.  It  is  strongly  recommended  that  these  fhncdonal  requirements  are 
turned  into  realization  requrrements  as  defined  by  SCZ4/N171 00  acceptance  of  foe  NWI  and  as  foe 
”oriring  flntfr  is  he»"g  prgiated.  This  means  that  if  tfaa  pityiMil  ^ehaHnle  it  ■dheicd  to,  then  the 
pwqntp^pKgitsvall  hetnniediHmalistrfdememtnheiiiriInrifittjntfaeoew  woikattfae 
SC24  meenng  in  Oember  1989.  This  does  Ihnit  dds  wede  to  eaeod  the  C(3d  to  indnde  only  those 
B^v^tiiTWfngnge  which  have  been  accepted  at  that  dine.  Tins  should  ensure  that  prugress  can  be 

momarred,  problem  areas  identified  eariy  in  foe  project,  and  these  urgent  needs  OT  COM  users  met 

in  a  dmeiy  mfaxon. 
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Final  Report  of  CGM  Elxtension  Study  Period 
Lofton  Henderson,  Rapporteur 
10  August  1989 


1.  INTRODUCTION 

At  its  July  1988  meeting,  ISO/IEC  JTC1/SC24  passed  a  nximber  of  resolutions 
establishing  study  groups  and  study  periods  on  future  computer  graphics  standards 
work  within  SC24.  Resolution  9  established  a  study  period  to  examine  the  need  for 
further  extensions  to  the  Computer  Graphics  Metafile  standard  (CGM,  ISO 
8632/1987).  Further  extensions  had  been  proposed  in  order  to  meet  the  require¬ 
ments  of  application  areas  such  as  engineering  drawing,  technical  publishing,  and 
graphic  arts,  and  had  commonly  been  referred  to  as  “Addendum  3.” 

One  set  of  extensions,  .\ddendum  1.  was  already  in  an  advanced  state  of  processing. 
A  second  set.  Addendum  2  (for  3D),  was  technically  an  active  project  but  was 
without  a  document  editor  and  was  not  progressing.  Both  of  these  projects  wei-e 
being  processed  under  ISO  rules  for  addenda,  according  to  resolutions  at  the  SC24 
plenary  in  September  1986.  These  resolutions  established  the  addenda  projects 
without  New  Work  Item  review  and  ballot. 

It  was  determined  by  SC24  that  the  proposed  Addendum  3  would  be  progressed 
according  to  the  new  NWI  procedures  in  N171.  Under  these  procedures  the  need 
for  such  a  project  would  be  studied  by  a  study  period,  a  requirements  document 
would  be  generated  and  reviewed  by  the  requirements  rapporteur  group  within 
SC24/WG1,  the  position  of  the  proposed  work  in  SC24  reference  models  would  be 
reviewed  by  the  reference  models  group  within  WGl,  and  finally  an  .N\V7  would  be 
geneiated  and  balloted. 

Key  technology  areas  of  .Addendum  3  include  advanced  graphical  text  capabilities 
and  advanced  geometric  primitives.  Because  these  technology  areas  are  expected  to 
be  shared  among  several  of  the  next  generation  of  SC24  standards,  study  groups 
were  established  to  examine  each  of  the  areas.  The  .Addendum  3  study  period  was 
directed  to  coordinate  closely  with  these  two  groups. 

2.  SUMMARY  OF  RESULTS 

The  Study  Period  concluded  that  the  extensions  referred  to  as  "Addendum  3"  are 
needed  and  must  be  expedited  if  CGM  is  to  continue  to  be  an  important  standard. 

The  provisions  of  N171  were  followed.  A  requirements  document  and  reference 
model  statement  were  produced  and  submitted  to  WGl.  A  New  Work  Item  propo¬ 
sal  was  drafted  and  submitted  to  SC24  for  a  three  month  ballot.  The  ballot  passed 
with  no  negatives,  and  a  slightly  revised  NWI  is  currently  being  balloted  in  JTCl. 
A  Working  Draft  of  Addendum  3  has  been  produced  and  is  currently  undergoing  a 
three  month  comment  period  in  SC24. 
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3.  HISTORY 
3.1  Munich  Meeting 

The  first  meeting  of  the  Study  Period  was  held  in  Munich,  F.R.  Germany.  18-20 
January  1989.  It  was  held  in  parallel  with  the  initial  meetings  of  the  Text  Study 
Group  and  the  Product  Data  Geometry  Study  Group.  These  two  groups  met  for 
the  first  half  of  that  week,  and  the  CGM  group  met  for  the  latter  half.  Many  of 
the  attendees  participated  in  one  or  the  other  of  the  technology  study  groups  and 
then  the  CGM  meeting. 

The  goals  of  the  meeting  were  to  ascertain  the  need  for  CGM  Addendum  3  and 
execute  the  first  steps  in  the  new  NWI  procedures  as  detailed  in  SC24/N171  — 
produce  a  requirements  document,  a  Reference  Models  statement,  and  a  draft  NWI. 
and  forward  these  documents  to  the  appropriate  groups. 

The  CGM  meeting  was  attended  by: 

Germany:  Brandenburg,  Moeller,  Schuur,  Zapomeul. 

UK:  Francis,  Mumford,  Thomas. 

US:  Bono,  Laris,  McConnell,  Stoll. 

The  meeting  was  chaired  by  Bono  in  the  absense  of  the  rapporteur  Henderson. 

There  were  no  ofilcial  inputs  to  the  meeting,  but  base  documents  referenced  in  the 
meeting  call  included  some  requirements  studies  and  a  draft  NMT  proposal. 

The  output  of  the  meeting  consisted  of: 

—  Minutes  (WG1/N36). 

—  Draft  Requirements  Document; 

—  Draft  New  Work  Item  proposal; 

—  Letters  to  the  WGl  Reference  Model  RG  and  the  Requirements  RG  requesting 
action  on  these  documents; 

The  detailed  results  of  the  meeting  are  contained  in  these  documents.  The  final 
versions  of  the  NWI  and  Requirements  Document  are  included  as  an  attachment  to 
this  report.  Significant  points  of  the  meeting  are  srunmarized  here. 

The  dependence  of  the  final  output  of  this  Study  Period  on  the  outputs  of  the  Text 
and  Product  Data  groups  was  recognized.  Concern  was  expressed  that  this  depen¬ 
dence  could  slow  the  work  down  considerably.  It  was  agreed  to  progress  the  work 
as  much  as  possible,  but  there  would  be  need  for  looking  at  the  final  outputs  of  the 
two  groups  when  they  become  available. 

There  was  some  discussion  of  how  to  progress  the  project  —  should  it  be  an  adden¬ 
dum?  The  general  feeling  is  that  it  should  not,  because  this  would  be  too  unwieldy. 
Decision  on  the  exact  method  of  processing  will  be  deferred  until  a  later  date. 
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A  schedxile  was  derived  which  would  result  in  IS  text  in  April  1991.  This  included  a 
tight  schedule  to  complete  all  of  the  required  NWI  processing  before  the  SC24 
meeting  in  October  1989.  By  the  end  of  that  meeting  there  should  be  a  complete 
list  of  reqxiirements  and  a  closed  list  of  elements. 

The  next  and  final  scheduled  meeting  was  set  to  be  in  Wmkoloa,  Hawaii.  2&*28 
June.  If  the  schedule  were  kept  this  meeting  would  process  the  results  of  the  SC24 
ballot  on  the  NWI  proposal. 

3.2  Between  Munich  and  Waikoioa 

The  Draft  NWI  and  Draft  Requirements  documents,  with  cover  letters  from  the 
rapporteur,  were  sent  to  the  Reference  Model  Rapporteur  Group  and  the  Require¬ 
ments  Rapporteur  Group  as  per  N171. 

The  Reference  Model  group  responded  informally.  Because  there  are  no  formal 
liaison  documents,  that  response  will  be  reviewed  here.  The  Reference  Models  RG 
pointed  out  that  there  could  be  some  problems  with  asserting  that  the  proposed 
CGM  .\ddendum  3  occupies  the  same  'level**  in  the  reference  model  as  CGM.  This 
problem  was  seen  during  the  processing  of  CGM  Addendum  1,  which  at  that  time 
contained  a  low-level  device  dependent  formulation  of  the  Pixel  .\rray  element  (it 
was  removed  from  Add.l  for  this  reason). 

The  Reference  Model  RG  felt  that  the  same  problem  could  arise  in  Add.3,  particu¬ 
larly  if  care  is  not  taken  in  formulating  the  additional  imaging  capabilities.  They 
pointed  out  that  if  the  realization  of  the  proposed  functions  of  Add.3  straddled 
stages  or  levels  in  the  Reference  Model,  then  CGM  would  have  to  make  a  choice: 
either  CGM-plus-addenda  is  at  a  well  defined  stage  in  the  pipeline  and  any  func¬ 
tions  to  the  contrary  would  be  proscribed  and  removed;  or  that  principle  no  longer 
pertains  and  CGM-plus-addenda  would  be  viewed  as  a  set  of  encoding  techniques  to 
be  applied  to  objects  at  different  stages  in  the  pipeline. 

The  general  consensus  of  the  CGM  Study  Period  and  the  WG3  CGM  Rapporteur 
Group  is  that  the  CGM  standard  should  remain  as  a  static  picture  capture  mechan¬ 
ism  whose  features  can  be  placed  at  approximately  the  current  CGM  level  in  the 
pipeline.  This  is  an  issue  that  CGM  must  keep  in  mind  while  progressing  any 
addenda.  Neither  CGM  nor  Reference  Models  have  been  able  to  precisely  specify 
what  criteria  determine  whether  functions  are  at  the  same  level  or  stage.  This 
question  is  bound  to  be  subject  to  some  interpretation,  and  will  likely  always  gen¬ 
erate  differing  opinions.  But  at  least  there  should  be  some  clustering  around  a  stage 
in  the  pipeline,  and  elements  which  create  recognizable  technical  problems  (such  as 
the  CGI  PIXEL  ARRAY  that  was  originally  included  in  Add.1)  should  be  avoided. 

The  Requirements  Rapporteur  Group  of  WGl  did  not  generate  a  formal  response 
to  the  Draft  NWI  and  Requirements  documents  either,  apparently  due  to  schedul¬ 
ing  difficulties.  There  is  in  the  WGl  document  register  (WGl  N41)  a  U.S.  position 
paper.  A  couple  of  comments  in  this  paper  seem  pertinent.  In  the  area  of  con¬ 
straints,  the  CGM  requirements  document  does  not  adequately  express:  requirement 
for  the  availability  of  resources;  requirement  for  timeliness  (must  be  done  by 
YYMM).  These  points  must  be  kept  in  mind  by  the  Metafile  Rapporteur  Group. 
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Because  there  were  no  requirements  for  change  from  either  of  the  WGl  rapporteur 
groups,  the  same  two  documents  that  were  produced  by  the  CGM  Study  Period  at 
Munich  therefore  went  to  the  WGl  plenary  meeting  in  late  February.  Recommen¬ 
dation  3  of  that  meeting  recommended  that  the  SC24  Secretariat  immediately  con¬ 
duct  a  three  month  ballot  on  the  NW^  so  that  the  results  could  be  processed  at  the 
final  scheduled  meeting  of  the  Study  Period,  2&-28  June  in  Waikoloa,  Hawaii. 

The  three  month  ballot  was  commenced  as  planned,  and  terminated  on  15  June. 

3.3  Waikoloa  Meeting 

The  Waikoloa  meeting  was  the  last  scheduled  meeting  of  the  CGM  Extensions 
Study  Period.  Its  purposes  were  to: 

—  process  the  results  of  the  NWI  ballot; 

—  revise,  if  necessary,  the  NWI  and  the  Requirements  Document; 

—  express  these  to  the  SC24  Secretariat,  to  be  forwarded  for  a  3-month  JTCl  bal¬ 
lot  to  close  before  Brazil. 

—  do  technical  work  on  the  Working  Draft. 

The  meeting  was  held  in  parallel  with  a  meeting  of  ANSI  X3H3.  It  was  attended 
by: 

Germany:  Eckhard  Moeller. 

UI<:  Alan  Francis,  Anne  Mumford. 

US:  Bruce  Garner,  Lofton  Henderson  (Rapporteur),  Mike  Laris  (provisional  Docu¬ 
ment  Editor),  Lori  Pearce,  Harold  Schechter. 

Anne  Mumford  Is  succeeding  Eckhard  Moeller  as  rapporteur  of  the  WG3  Metafile 
RG,  which  will  be  processing  Addendum  3. 

There  were  no  formal  inputs  to  the  meeting.  The  U.S.  produced  and  circulated  to 
attendees  a  baseline  document  to  serve  as  a  starting  point  for  a  working  draft.  The 
SC24  Secretariat  sent  NWI  ballot  results  by  Fax.  The  resxilts:  9  approve,  2  approve 
with  comments,  0  disapprove,  0  abstmn.  Comments  were  received  from: 

U.K.  —  stressing  importance  of  liaison  and  harmonization  with  closely 
related  groups; 

Japan  —  making  suggestions  that  the  NWI  and  Requirements  Document  be 
improved  by  providing  more  detmls. 

The  comments  of  the  U.K.  were  thought  to  be  addressed  adequately  in  the  current 
document.  Some  time  was  spent  discussing  the  comments  of  Japan.  The  additional 
detail  suggested  was  deemed  to  amount  to  a  Jiistification  of  the  requirements  that 
had  been  generated  from  various  sources.  While  such  more  detailed  information 
would  in  fact  be  of  interest,  it  was  thought  to  not  be  a  necessary  component  of  the 
documents  required  by  Nl71.  In  any  case  the  group  concluded  that  it  did  not  have 


68 


the  resources  to  develop  the  additional  information,  as  that  information  would 
essentially  have  to  come  from  the  source  of  the  requirement.  As  can  be  seen  from 
the  Requirements  Document,  those  sources  are  diverse  and  were  not  generally 
present  at  the  meeting. 

Consec  'lently,  minor  improvements  to  the  documents  were  made  and  the  rappor¬ 
teur  sent  these  on  to  the  SC24  Secretariat  for  commencement  of  the  SC24  ballot. 

By  the  time  of  this  meeting  there  had  been  no  further  activities  in  either  the  Text 
Study  Group  or  Product  Data  Study  Group,  and  so  the  NWl  and  Requirements 
Document  still  contain  references  to  the  work  of  those  groups  as  the  source  for 
specific  functional  requirements. 

There  was  a  liaison  meeting  between  the  CGM  group  and  a  number  of  outside 
experts  interested  in  STEP,  PHIGS,  PHIGS-f,  and  reference  models.  The  topic  was 
metafile  requirements  that  are  derivable  from  STEP  and  PHIGS{-1-).  As  far  as 
Add.3  is  concerned,  there  appear  to  be  few  new  requirements,  or  at  least  few  con¬ 
crete  requirements  were  generated,  because  Add.3  is  explicitly  a  2D  metafile.  The 
model  for  STEP,  computer  graphics  standards,  and  metafiles  that  seemed  to  get  the 
greatest  consensus  Involves  a  3D  file.  PHIGS+  is  seen  as  serving  presentation  and 
graphical  requirements  of  STEP,  and  it  was  felt  that  a  PHIGS+  workstation  state 
capture  file  (as  opposed  to  purely  graphical  capture)  was  the  sort  of  metafile  sup¬ 
port  needed.  Meeting  the  metafile  requirements  of  STEP  would  be  accomplished 
through  Addendum  2,  and  would  involve  some  modification  of  the  scope  of  .Add.2. 

The  group  discussed  resources.  It  is  agreed  that  there  are  not  sufficient  resources  to 
process  two  projects  (Add.2  and  Add.3).  '^he  current  WG3  Metafile  RG  members 
tend  to  be  more  interested  in  the  2D  work  (Add.3)  than  3D  work.  This  was  not  an 
official  position,  but  an  informal  survey.  It  is  clear  that  both  projects  cannot  be 
progressed  satisfactorily  if  more  people  are  not  available.  A  solution  could  involve 
collaborative  work  with  WG2  for  3D  metafiles. 

It  was  generally  agreed  by  the  group  that  Addendum  3  should  not  be  progressed  as 
an  addendum,  at  least  not  beyond  the  earliest  stages.  Rather,  it  and  Add.l  should 
be  folded  into  the  CGM  standard  to  produce  a  complete  new  document.  This  issue 
will  be  addressed  by  the  WG3  Metafile  RG  when  it  commences  work  on  the  pro¬ 
ject. 

There  was  time  to  work  on  the  Add.3  baseline  document  during  the  meeting.  The 
group  divided  into  technical  subgroups  examining  particular  topics.  As  a  result  the 
baseline  document  was  advanced  sufficiently  that  the  group  feeb  it  b  suitable  for 
the  status  of  Working  Draft.  It  was  sent  to  the  SC24  Secretariat  for  immediate  cir¬ 
culation,  with  the  hope  of  getting  early  comments  that  could  be  processed  at  Brazil. 

4.  CURRENT  STATUS  &  PENDING  MATTERS 

The  NWI  and  Requirements  Document  are  before  JTCl  for  a  3-month  ballot.  It  is 
hoped  that  thb  will  close  before  Brazil.  Unfortunately  some  long  delays  have  been 
reported  in  getting  previous  items  through  JTCl,  and  thb  may  adversely  affect  the 
Add.3  schedule. 
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The  WG3  Metafile  Rapporteur  Group  will  have  to  ascertain  the  level  of  resource 
committment  for  Add.3,  presumably  at  the  Brazil  meeting. 

The  NWI  and  RequTrements  Document  commit  Add.3  to  a  certain  level  of  coordi¬ 
nation  with  the  output  of  the  Text  Study  Group  and  the  Product  Data  Geometry 
Study  Group.  The  Hnal  reports  of  these  two  groups  will  have  to  be  examined  to  see 
if  any  further  specific  requirements  for  Add.3  are  implied. 

Before  the  Working  Draft  stage  is  complete,  the  Metafile  RG  must  finalize  the 
agreed  set  of  ftmctioDS  for  Add.3  —  this  should  be  done  at  Brazil. 

A  Working  Draft  is  currently  being  circulated  for  NWI  comment.  Early  comment 
is  hoped  for  by  Brazil,  so  that  work  may  take  place  at  Brazil. 

5.  COMMENTS  ON  THE  STUDY  PERIOD 

Herein  are  personal  comments  and  observations  of  the  rapporteur,  both  on  the  new 
procedures  and  on  this  Study  Period. 

The  procedures  outlined  in  N171  are  excellent  in  principle.  Some  improvement  was 
absolutely  needed  over  the  processes  by  which  CGM  itself  was  standardized,  and  by 
which  Add.1  and  Add.2  were  undertaken.  In  the  case  of  CGM  perhaps  1-2  years  of 
delay  was  incurred  by  fimdamental  dis^reements  over  what  was  being  standard¬ 
ized.  In  the  case  of  Add.2,  the  scope  and  purpose  have  shifted  several  times,  the 
effort  is  has  not  been  sufficiently  driven  by  agreed  requirements,  and  in  consequence 
little  progress  has  been  made.  In  the  case  of  Add.l,  these  problems  were  potentially 
present  again,  but  fortuitously  there  was  reasonable  consensus  among  those  working 
on  the  project  and  good  progress  was  made. 

The  resiilt  of  the  procedures  is  that  11  voting  nations  have  endorsed  the  scope  and 
purpose,  and  the  high  level  functional  definition  of  Addendum  3,  and  no  voting 
nations  are  opposed.  The  hidden  disagreements  that  have  interferred  with  previous 
metafile  work  should  not  be  a  problem  for  Addendum  3. 

There  have  been  problems  with  the  process  however.  The  main  problem  i&that  it 
has  taxed  participants’  resources  too  heavily.  There  were  too  many  meetings  and 
too  much  reqmrement  for  liaison  for  the  resources  available. 

As  a  secondary  effect  of  the  resourt*  shortage,  certain  steps  specified  in  N171  were 
missed  or  passed  as  formalities.  No  formal  input  ever  came  back  to  the  Study 
Period  from  the  Requirements  RG  or  the  Reference  Model  RG  before  the  Require¬ 
ments  Document  and  NWI  went  out  to  SC24  for  ballot.  This  was  due  in  one  case 
to  a  liaison  that  was  missed  for  lack  of  time  and  in  the  other  case  to  a  meeting 
which  had  to  be  cancelled. 

The  content  of  the  Add.3  project  was  made  dependent  upon  the  output  of  two 
technology  study  groups.  All  three  groups  started  off  with  a  high  activity  level. 
One  of  the  technology  groui»  resulte  i  in  specific  items  that  could  be  adopted  by 
the  Add.3  NWI;  the  other  did  not  generate  such.  In  both  cases,  the  work  of  Add.3 
Study  Period  cannot  be  complete  until  the  final  reports  of  the  two  groups  are  avail¬ 
able,  at  Brazil,  16  months  after  the  process  commenced. 
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The  AdcLS  Study  Period  was  somewhat  fortunate  in  the  timing  of  events.  Once  the 
initial  meetings  happened  in  January,  the  meetings  of  the  Reference  Model  group, 
the  Requirements  group,  WGl  plenary,  and  the  SC24  AG  happened  very  soon 
after.  Other  projects  following  the  procedures  of  Nl/1  could  be  less  fortunate  and 
could  incur  significant  delay.  If  all  of  the  dependencies,  those  required  by  Nl71  and 
those  required  by  technical  liaison,  had  been  rigidly  observed  it  is  easy  to  imagine 
that  the  process  could  take  significantly  longer  than  this  Study  Period. 

In  the  balance  the  process  was  beneficial.  New  standards  should  be  driven  by 
agreed  requirements  and  should  have  consensus  on  scope  before  work  begins.  How¬ 
ever  given  the  current  environment  and  pressure  on  resources  the  procedures  need 
to  be  simplified  and  streamlined. 
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Attachment  6: 
Addendum  3  Working  Draft 
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ANSI  X3H3 


Informaoon  Processing  Systems 


Computer  Graphics  - 


MeultJe  for  the  Storage  and  Transfer 
of  Picture  Description  Information 


Pan  1 

Funcuona]  Spccificauon 
(Clause  3) 

Addendum  3 

Draft  Document  2.0 
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Paged 


Sutxiause  3;  add  or  change  the  following  enthes: 

colour  model:  A  spedficaiion  of  a  3D  colour  coordinate  system  and  a  3D  subspace  in  the  coordinate 
system  within  which  each  displayable  colour  is  represented  by  a  point.  Some  colour  models  include  a 
fourth,  redundant,  dimension  to  allow  the  independent  lepresenuuon  of  blade.  For  the  purpose  of  ISO  8632 
colour  model  refers  to  one  of  RGB.  QE  L*u*v».  or  CYMK. 

colour  sclectioo  mode:  Indicator  as  to  whether  colour  selection  is  to  be  direct  (by  specifying  a  colour 
value)  or  indexed  (by  ^wifying  an  index  into  a  table  of  colour  values).  See  COLOUR  VALUE. 

colour  represenution  method:  Indicator  as  to  which  of  three  colour  models  (RGB.  CIE  L*u*v*. 
CYMK)  or  spot  colour  is  being  used  to  represent  colour  values.  Sec  COLOUR  VALUE.  SPOT 
COLOUR. 

colour  value:  The  character  string  (for  spot  colour)  or  values  of  the  point  components  (for  colour  mode!) 
describing  a  colour. 

RGB:  An  additive  colour  model,  well  matched  to  colour  display  monitors,  whose  values  are  defined  by  the 
narmalized  weights  of  Red.  Green,  and  Blue  components. 

CIE  L*u*v*;  A  colour  model  defining  an  absolute  colour  space  based  on  colour  matching  experiments 
whose  components  are  L*  (Lightness)  and  u*.  v»  (Chromaticness). 

CYMK:  A  subtractive  colour  model,  common  in  the  printing  industry,  which  has  cyan,  magenta,  yellow, 
and  black  components. 

Reference  Colour  Model;  Basic  colour  model  within  CGM  relative  to  which  relationships  to 
specifiable  colour  models  (RGB.  CYMK,  and  CIE  L*u*v*)  are  calibrated.  The  reference  colour  model  is 
defined  by  the  CIE  1931  standard  coiorimcinc  system  (XYZ). 

spot  colour;  An  exactly  defined  colour  wiih  a  registered  name. 
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ANSI  X3H3 

Information  Processing  Systems  ~ 

Computer  Graphics  — 

Metafile  for  the  Storage  and  Transfer 
of  Picture  Description  Infctfmation 


Pan  1 

Functional  Specification 
(Cbuse  4) 

Addendums 

Draft  Ooctoneni  2.0 
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Page  10 


Subclause  4 J:  Add  the  following  to  the  list  of  eiemcnts  given  in  the  first  paragraph  of  this 

COLOUR  REPRESENTATION  METHOD 
PONT  DEFINITION 
FONT  ATTRIBUTES 
CHARACTER  KERNING  MODE 
CHARACTER  KERNING  TABLE 


Page  10 

Subclause  422.1:  Add  the  following  to  the  list  of  elements  given  in  the  second  paragraph  of  this 

COLOUR  REPRESENTATION  METHOD 
CONIC  ARC 

CONIC  ARC  TRANSFORMATION  MATRIX 

parametric  spline  curve 

RATIONAL  B-SPLINE  CURVE 
RATIONAL  B-SPUNE  CURVE  CLOSED 


Page  11 

Subclause  4.3.2^‘  Add  the  following  lo  the  list  of  elements  given  in  the  second  paragraph  of  this 
clause: 

COLOUR  REPRESENTATION  METHOD 
FONT  DEFINITION 
FONT  ATTRIBUTES 
CHARACTER  KERNING  MODE 
CHARACTER  KERNING  TABLE 


Page  II 

Add  the  following  as  subclause  4.3.4 
4J.4  Font  Elcmeats 

The  FONTME7RIC  DEFTNITTON  element  is  provided  to  all  permit  exact  typographic  placement  of  the 
character  glyphs  specified  within  a  text  string.  Using  FONTMETRIC  DEFINITTON,  the  initial  chaiacter  in 
a  text  string  would  be  placed  at  the  specified  coordinates,  and  each  subsequent  character  would  be  offset  by 
the  width  and  right  si^  bearing  of  the  previous  character  and  by  iu  own  left  side  bearing,  if  character 
kerning  is  also  in  effect,  then  the  inter  character  space  would  also  be  adjusted  by  the  specified  kern  value. 
The  character  height  and  offset  from  the  baseline  are  used  to  detennine  i>ni»rttiffe  siring  ascent, 

■iddesceaL 

TTie  PONT  ATTRIBUTES  element  can  be  used  to  select  a  best  fit  fmu  if  an  match  is  not  available  on 
a  specific  device. 


Page  12 


Subclause  4.42,  first  line: 
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Qiange  "direct  (RGB)  colour’ 
into  "direa  colour’ 


?age  14 


Subclause  4.4.6,  second  paragraph,  first  line: 
Change  ”RGB’ 
into  'a  direa  colour* 


Page  14 


Subclause  4.S.2:  add  the  following  to  the  end  of  the  subclause 

The  IMAGE  APERTURE  is  not  affected  by  the  seuing  of  the  CUP  INDICATOR  element.  Aperture 
setting  for  pel  amy  elements  is  assumed  to  be  always  on'.  The  default  IMAGE  APERTURE  is  listed  in 
claused. 


Add  the  following  as  subclause  4.5.3: 

4.5.3  Aperture. 

Selection  of  the  region  of  interest  within  a  pel  amy.  whether  clipped  by  the  CUP  RECTANGLE  or  not.  is 
accomplished  using  the  IMAGE  APERTURE.  Since  the  IMAGE  AP^TURE  'mode'  is  always  assumed 
to  be  'on',  the  display  of  all  pel  amy  elements  is  aiwa)'S  considered  to  be  controlled  by  an  aperure  seiung. 
The  default  image  aperture  is  listed  in  Cause  6.  The  IMAGE  APERTURE  element  thus  affecu  all 
subsequent  pel  amy  dements  that  follow  in  the  metafile  until  the  aperture  is  overridden  by  the  appearance 
of  the  next  IMAGE  APERTURE  dement. 


Page  IS 

Subclause  4.6:  add  the  following  to  the  list: 
CONIC  ARC 

COMPRESSED  PEL  ARRAY 
TILED  PEL  ARRAY 
PEL  ARRAY  REFERENCE  POINT 
PARAMETRIC  SPLINE  CURVE 
RATIONAL  B-SPUNE  CURVE 
RATIONAL  B-SPUNE  CURVE  CLOSED 


Page  15 

Subdause  4.6:  add  the  following  to  The  line  elements  are:”  list: 
CONIC  ARC 

parametric  SPLINE  CURVE 
RATIONAL  B-SPUNE  CURVE 


Page  16 
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Subclause  4.6:  add  the  following  to  The  flUed-area  elements  are:’  list: 
RATIONAL  B-SPUNE  CURVE  CLOSED 


Page  16 

Subclause  4.6:  change  The  cell  array  element  is:”  to  The  cell  array  elements  are:’  and  add  the 
foUowing  to  the  lisc 

COMPRESSED  PEL  ARRAY 

TILED  PEL  ARRAY 

PEL  ARRAY  REFERENCE  POINT 

Page  16 


Subclause  4.6.L1:  change  subclause  to  read  the  following: 

4.6  JJ  Description.  There  are  two  general  line  elements  -  POLYLINE  and  DISJOINT  POLYLINE  •  four 
line  elements  rdating  to  circles,  ellipses  and  conic  arcs,  and  two  elements  that  relate  to  spline  curves. 


Page  16 


Subclause  4.6.1. 1:  change  the  end  of  the  subclausc: 

CONIC  ARC  generates  a  parabolic,  hyperbolic  or  elliptical  arc:  the 

parameterization  of  the  arc(s)  is  described  in  5.6J(. 

XXX  SPLINE  CURVE  generates  a  single  spline  curve;  two  separate  parameterizations  of 

the  spline  curve  are  possible;  these  are  described  in  5.6.X  and 
5.6.X+1 


Page  16 

Subclause  4.6.1  J:  change  the  last  sentence  of  the  subclause  to  read: 
The  ARC  and  SPLINE  primitives... 

Page  17 

Subclause  4.6.4. 1:  change  the  second  sentence  of  the  subclause  to  read: 
In  addition  there  are  seven  elements  that...’ 


Page  18 

Subclause  4.6.4. 1:  add  the  foUowing  to  the  end  of  the  subclause: 

RATIONAL  B'SPLINE  CURVE  CLOSED  generates  a  B'^line  curve  the  set  of 

styles  is  the  same  as  for  POLYGON. 

Page  18 
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Subclause  4.6.4  J  2nd  paragraph:  change  the  sentence  U}  read: 


The  circular,  elliptical  and  B*spline  (ill  primitives...' 


Page  18 


Add  the  following  as  subclause  4.6.5.1: 

4.6  J.J  Pel  Array  Elements 

COMPRESSED  PEL  ARRAY  represents  a  rtetangular  binary  image  compressed  according 

to  the  CCITT  T4  or  T6  facsimile  recommendations:  two 
parameterizations  are  possible,  one  conesponding  to  the 
normal  facsimile-size  image,  and  a  tiled  format  for  large 
images;  the  elements  are  described  in  5.6.X  and  S.6JC-f  1. 

TILED  PEL  ARRAY  represents  a  series  of  equally  contiguously  positioned 

individual  raster  images,  or  'tiles*.  The  first  tile  is  placed  at 
the  PEL  ARRAY  REFERENCE  POINT,  and  then  the  tiles 
are  placed  in  sequence  in  the  direction  of  the  pel  path  and 
line  progression  as  shown  in  figure  X.  The  tiles  are 
numbered  by  the  tile  index  contained  in  the  pel  array 
identiner  parameter  of  each  tile. 


Reference  Point 


Figure  X  Ordering  and  layout  of  tiles  by  index 


4.6  1.1  Attributes.  The  orientation  and  dimensiems  of  the  pel  amy  demenu  is  controlled  by  the  PEL 
ARRAY  ORIENTATION  and  PEL  ARRAY  DIMENSIONS  eiemenu.  The  PEL  ARRAY 
ORIENTATION  elemem  specifies  the  the  ditection  of  the  layout  of  ix.  the  pel  path,  in  90  degree 
tneremeots.  relative  to  the  VDC  axis.  This  elemem  also  ^ecifies  the  directiao  of  the  layout  of  lines  of 
pels,  Le.  the  line  progression,  in  180  degree  incremems  relative  to  the  pel  pmh  direction.  The  pel  path  and 
line  progressoo  are  constrained  to  be  at  right  angles  lo  one  another. 

4.6J.1 2  Positioning.  The  position  of  a  pel  amy  element  is  defined  by  the  PEL  ARRAY  REFERENCE 
POINT  element.  The  reference  point  element  affects  the  position  of  all  pel  amy  dmnents  that  follow  it  in 
the  metafile,  until  it  is  overridden  by  a  subsequent  PEL  ARRAY  REFERENCE  POINT  ELEMENT.  The 


83 


t 


visual  effect  on  whatever  might  already  be  positioned  at  or  near  a  given  reference  point  by  the  overlay  of  a 
pel  array  element  is  implementaiion-dependenu 

4.6JS.IJ  Tiling.  TTie  tiling  mechanism  specified  is  based  on  the  Tiled  Raster  Interchange  Format  work 
that  has  been  developed  relative  to  MIL-STD-1840  and  ISO  8613  Pan  7.  The  TILING  MODE  conu-ol 
element,  when  ‘on*,  indicates  ihv.  all  subsequent  COMPRESSED  PEL  ARRAY  elements  are  u.  oe 
considered  individual  tiles  within  the  tiled  image  until  the  a  subsequent  TILING  MODE  element  sets  the 
mode  to  'ofT.  If  the  number  of  ’tiles’  defined  while  tiling  mode  is  ’on*  is  less  than  the  number  indicated 
by  the  Tn-Pn  pel  ARRAY  element,  then  the  missing  tiles  are  treated  as  encoded  as  ’null  background’. 
The  tiling  offset  parameter  defines  the  position  of  the  acnial  pel  array  within  tile  qace.  relative  to  the  PEL 
ARRAY  REFERENCE  POINT.  All  tiles  cover  a  portion  of  the  pel  array,  the  portions  of  the  tile  space 
outside  of  the  tile  array  ate  artifacts  of  tiling  and  cimtain  no  ittfonnatiem. 


Page  19 


Subdause  4.6.7:  add  the  following  after  the  subclause: 

4.6.8  Conic  Are  Element. 

A  Conic  Arc  is  a  bounded  connected  portion  of  a  parent  conic  curve  which  consisu  of  more  than  one  point. 
The  parent  arc  is  either  an  ellipse,  a  parabola,  or  a  hyperbola. 


4.6.8.J  Parameterixtttion.  A  conic  arc  is  defined  by  the  end  points  and  the  six  parameters.  The  conic  arc 
itself  is  defined  by  the  six  parameters  in  the  following  equation; 

A(x2)  ♦  BXY  ♦  CCY^)  +  DX  +  EY  ♦  F  -  0 

This  parameterizadon  assumes  that  VDC  space  is  4  quadrant  canesian  coordinant  space.  The  CONIC  ARC 
TRANSFORMATION  MATRIX  dement  is  then  used  to  properly  position  the  arc  in  the  quadrant  of  VDC 
qace  defined  by  the  VDC  EXTENT  element 

4.6 Geometric  Concepts.  The  conic  arc  is  defined  by  the  start  point,  end  point  and  the  six  parameters 
A*F.  To  determine  the  form  of  the  conic  arc.  the  quantities  Ql,  Q2  and  Q3  are  defined  as  follows: 

I A  B/2  D/21 
Ql  ■  determinant  of  I  B/2  C  E/2  I 
I  D/2  E/2  FI 

Q2  ■  determinant  of  I  A  B/2  I 
IB/2  C  I 


Q3-A^C 

If  Q2>0  and  (Ql*Q3)<0.  then  the  arc  is  dliptical; 
if  Q2<0  and  QloO.  then  the  arc  is  hyperbolic; 
if  Q2a0  and  QloO.  then  the  arc  is  parabolic 

In  the  case  where  the  conic  sc  is  dliptical.  to  distinguish  the  arc  in  question  &om  its  compliment,  the 
direetion  of  the  sc  with  respea  to  VDC  space  must  be  from  start  point  to  end  point  in  a  counierdockwise 
direct. 

In  the  case  where  the  conk  arc  is  parabolic  or  hyperbolk,  the  parameterizatian  defines  a  unique  portion  of 
the  parabola  or  a  unique  portion  of  a  branch  of  the  hyperbola,  thus  the  direction  is  irrelevant. 


4.6.9  Spline  Curve  Elements 


f- 
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The  eiemenis  described  in  this  section  were  derived  from  IG£S  V3.0.  and  are  specialized  for  the  case  of  two 
dimensions. 


4.6S.1  Parametric  Spline  Curve.  The  parametric  spline  curve  is  a  sequence  of  parametric  polynomial 
segments.  The  definition  of  ‘his  class  of  curves  is  generalized  to  allow  for  the  represenutioi  of  many 
different  parametric  spline  curves  using  only  one  element.  The  following  curve  types  have  been  assigned; 


1:  linear 
2:  quadratic 
3:  cubic 

4:  WilsoO'Fowier 
5:  modiited  WiIson>Fbwler 
6:  B  spline 

4.6.9.1J  Parometeruatian.  The  degree  of  continuity  parameter  indicates  the  smoothness,  cr  continuity  of 
the  curve  with  respect  to  arc  length.  The  curve  can  either  be  continuous  at  all  break  points,  continuous  and 
have  slope  continuity  at  all  break  points,  or  be  continuous  and  have  both  slope  and  curvature  continuity  at 
aQ  break  points. 

The  number  of  segments  parameter  is  the  number  of  polynomial  segments  to  be  used  to  define  the  curve. 
F?eh  X,y  polynomial  segment  is  evaluated  using  the  eight  polynomial  coefficients  associated  with  that 
segmeru  (AX3X,CX,DXAY3Y.CY,DY).  Each  segment  is  delimited  by  its  respective  breakpoint. 

4.6.9. J  .2  Geometric  Concepts.  The  following  cubic  polynomial  equations  will  return  the  coordinates  of 
the  points  of  the  i>th  segment  of  the  curve.  Note  that  the  coefficients  D,  or  C  and  D  will  be  zero  if  the 
polynomials  are  of  degrees  2  or  1,  respectively: 

X(u) «  AX(D  ♦  BX(i){s)  ♦  CX(D(s2)  ♦  DX(iXs^) 

Y(u)  •  AY(i)  +  BY(i)(s)  ♦  CYfiXs^)  +  DYfiXs^) 

where  T(i)  <■  u  <■  T(i4'l),i«l,...>l  and  s  »  u  •  T(i). 

The  xrminaie  point  and  derivatives  are  derived  without  computing  the  polynomials  by  evaluating  the  Nth 
polynomials  and  derivatives  at  u  <■  T(N  1).  These  dau,  divided  by  the  appropriate  factorial  (i.e.  the  second 
derivative  divided  by  2!,  the  third  by  3!).  ate  used  as  the  N-f]  or  terminate  point  values. 


4.6S2  Rational  B-Spline  Curve. 

4.6S2.1  Parameuraadon.  The  Rational  B<SpIine  curve  is  parameterized  where: 

flanjiaram  <■  t  <■  end_param, 

T(0}  <M  Stan jatam  <  end jvam  <m  T(N) 

Thus  for  any  parameter  value  t  between  T(0)  and  T(K-«-l),  the  sum  of  the  basis  functions  satisfies  the 
following  idrauty: 

bO(t)-t.bl(t)  +  .-.  +  bK(t)«l. 

If  all  of  the  wei^ts  in  the  weight  list  are  not  equal,  then  the  equuion  type  is  rational.  Otherwise,  if  ail  of 
the  weights  are  equal,  then  all  of  the  weights  camcel,  the  denominators  sum  to  one  and  the  equation  type  is 
polynomial. 

4.6.922  Geometric  Concepts.  The  parametric  equation  governing  the  deflniticm  of  the  rational  B-spline 
carve  is  shown  in  the  following  expression: 
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W(0)*P(0)-b0(t)  +  W(l)*P(l)»bl(t)  W(K)-P(K)-bK(l) 


W(0)*b0(t)  +  W(l)*bl(t)  W(K)*bK(t) 

where  W(i}  are  the  weights.  P(i)  are  the  control  points  and  bi(t)  are  the  functions.  The  basis  functions 
are  all  iM>n>nep*ive  piecewise  polj'nomials  determined  by  tte  degree  and  the  knut  sequence.  The  knot 
sequence  is  a  non*deaeasing  list  of  real  numben  T(-M)....T(0)....T^-*-l).  Each  basis  function  is  supplied 
for  the  knot  sequence  interval  [T(i-M),T(i+l)],  where  M  is  the  degree  of  the  basis  function.  Between  any 
two  adjacent  knot  values,  the  corresponding  basis  function  can  be  expressed  as  a  single  polynomial.  The 
basis  functions  are  defined  as  follows: 

Let  N(tlti*m....4i<^l)  denote  the  B-Spline  basis  function  of  degree  m  supported  on  the  interval  [d-m.ti-t-l]. 
Ibe  functions  of  degree  d  are  defined  with  respea  to  those  of  d- 1 ,  as  in  the  following: 


(t-tO)N(tltO,-jd-l)  (ul-t)N(tO_jd) 

N(tlt0..-4d)  «  — '  "  — . —  ♦...+  - 

td-l-tO  tti-il 

Since  the  denominators  wQl  be  zero  (0)  in  some  cases,  the  convention  0/0  «  0  is  adopted  for  this  definition. 


4,XJf  Compound  Line 

The  compound  line  elements  consist  of  the  two  elements.  BEGIN  COMPOUND  LINE  and  END 
COMPOUND  LINE.  These  elemenu  permit  the  definition  of  a  line  that  consists  of  a  number  of  distinct 
elements,  such  as  straight  lines  and  arcs,  which  is  treated  as  if  it  were  a  single  line  element.  Thus,  for 
example,  line  style  would  apply  without  change  or  interruption  past  a  straight  line  segment  onto  a 
following  arc  segment.  Likewise,  the  ends  of  the  various  component  elements  of  the  compound  line  are 
not  treated  as  line  end  caps  but  rather  as  line  joints. 


4.X.X  Compound  Text  Path 

The  compound  text  path  elements  consist  of  the  two  elements,  BEGIN  COMPOUND  TEXT  PATH  and 
&fD  COMPOUND  TEXT  PATH.  It  is  functionally  idenucal  to  Compound  Line,  except  that  it  is  used  as 
a  base  line  for  text  ^dacemem,  tather  than  drawn  by  an  interpreter. 

The  compound  Text  Path  permits  arbitrary,  complex  placement  of  text.  Each  font  symbol  is  placed  with 
its  reference  point  and  alignment  according  to  a  tangent  to  the  Compound  Text  Path.  This  implicit  tangent 
is  the  logical  base  line  for  each  character  cdl.  If  a  symbol's  reference  point  aligns  with  the  junction  of  two 
line  elements  of  the  Compound  Text  Path,  the  logical  base  line  is  the  line  perpendicular  to  the 
perpendicular  bisector  of  the  langenu  of  both  elements,  posing  through  the  reference  pt^  Positioning  of 
subsequent  symbols  is  based  upon  the  distance  between  symbols  assuming  a  straight  base  line,  but  wi^rped 
along  the  gmerali*?**  curve  of  the  Compound  Text  Path.  If  there  is  more  text  than  path,  the  path  for  the 
excess  text  is  the  straight  line  described  by  the  tangent  to  the  last  elemem  of  the  Compound  Text  Path. 


4JCJ1  Picture  Compositiun 

The  picture  composition  elemenu  consist  of  BEGIN  CUP  REGION,  END  CUP  REGION,  BEGIN 
SHIELD  REGION.  END  SHIELD  REGION,  CUP  INDICATOR,  and  SHIELD  INDICATOR. 

The  concepu  of  clip  and  shield  regions  are  complementary.  The  clipping  process  discards  everything  that  is 
visually  outside  the  dip  region  whereas  the  shielding  process  disnrds  everything  that  is  inside  the  shield 
region.  Whether  clipping  and  shidding  are  in  eflea  is  determined  by  the  respective  settings  of  the  CLIP 
INDICATOR  and  SHIELD  INDICATOR  (each  is  either  ON  or  OFF). 
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Due  to  being  able  to  define  what  amounts  to  closed  figures  for  these  regions,  the  clip  region  and  shield 
legic  ns  can  each  isovide  a  dieting  and  a  shielding  capability  ai  the  same  time.  For  example,  a  'polygon 
with  a  hole”  las  an  outer  bound^  and  an  inner  boundary,  the  'filled  area*  of  such  a  clipping  region  would 
be  preserved  with  the  area  outside  the  'filled  area'  (including  the  contents  of  the  hole')  b^g  removed  from 
the  picture.  The  shielding  region  has  a  complementary  interpretation:  the  'filled  area'  itself  is  removed 
from  the  picoee. 

Note  that  the  shielding  effect  of  a  clip  region  *11016'  is  indqrendent  of  the  SHIELD  INDICATOR  and 
likewise,  the  doping  effect  of  a  shield  region  liole'  is  independent  of  the  CLIP  INDICATOR. 

Page  37 


Subdause  4.7.7:  rqdace  the  current  text  body  with  the  following: 

The  CGM  must  be  able  to  represent  colours  in  a  manner  suitable  to  a  broad  spectrum  of  graphical  devices 
and  systems.  Towards  this  g^  the  CGM  uses  three  colour  models  (RGB,  CIE  L*u*v*,  CYMK)  and  spot 
colour.  The  Metafile  Descriptor  dement,  COLOUR  REPRESENTATION  METHOD,  allows  metafile 
generators  to  specify  which  one  is  being  employed. 

The  RGB  additive  edour  modd  uses  a  3‘tuple  of  values  providing  the  normalized  weight  of  the  red  (R). 
green  (G).  and  blue  (B)  components  of  the  desired  colour.  This  model  is  used  in  colour  monitors,  film 
writers,  and  input  scanners. 

The  CIE  L*u*v*  uniform  colour  model  uses  a  3<upie  of  values  providing  the  normalized  luminance  (L*), 
red-green  chromaticness  (u*),  and  blue-ydlow  chromaticness  (v*)  components  of  the  desired  colour.  The 
advantages  of  the  modd  over  the  others  are  (1)  it  separates  chromaticness  from  luminance  (allowing  for  easy 
monochrome  display),  (2)  it  is  a  uniform  qnce  for  small  colour  differences  (the  Euclidean  distance  between 
two  points  in  this  modd  is  more  or  less  proportional  to  their  perceived  difference),  and  (3)  it  is  an  absolute 
colour  modd  based  colour  matching  experiments  (thus  being  device  independent  and  not  requiring  colour 
ooRecdon). 

The  CYMK  subtractive  colour  modd  uses  a  4-ttipre  of  values  providing  the  normalized  weights  of  the  cyan 
(Q,  yellow  (Y).  magenu  (M),  and  black  (K)  components  of  the  desired  colour.  ^Iiis  model  is  used  by 
printers  said  Graphics  Arts  drum  scanners.  In  theory,  cyan,  magenta,  and  yellow  are  meant  to  conespond  to 
the  red,  green,  and  blue  of  the  RGB  model.  In  practice,  actual  inks  used  for  colour  printing  only 
approximate  this  criterion.  Black  ink  is  added  to  attain  a  greater  dynamic  range  than  is  possible  with  three 
coloun  alone.  In  particular,  it  allows  the  attainment  of  a  much  richer  black  than  would  be  possible  using 
only  the  first  three  inks. 

Spot  colour  uses  a  character  string  representing  a  registered  or  private  colour  name  (similar  in  format  to 
named  fonts).  Use  of  the  fanner  is  recommended  for  metafile  transportability,  because  registration  ensures 
unique  naming  of  colours.  Spot  colours  are  regisiered  in  the  ISO  International  Register  of  Graphical  Items, 
which  is  maintained  by  the  Registration  Authority.  When  a  spot  colour  has  been  ai^ved  by  the  ISO 
Woridng  Group  on  Gxnputer  Graphics,  the  colour  name  will  be  assigned  by  the  Re^tration  Authority. 
Each  registered  colour  will  be  spedCed  in  terms  of  its  QE  L*u*v*  coordinates. 

The  CGM  provides  two  mechanisms  for  colour  selection:  'direa*  and  ’indexed*.  In  ’direct*  colour  selection, 
the  colour  is  qtectfied  by  providing  values  for  its  normalized  components  (colour  model)  or  by  providing 
the  character  suing  defining  iu  tiame  (spot  colour).  (The  term  'dir»  colour  value*  will  rider  to  any  direct 
colour  jpxifier,  ^  the  term  ’direa  colour  modd  value*  will  refer  only  to  a  direa  colour  qxcifier  of  a 
ooioar  modd  (as  opposed  to  spot  colour)).  In 'indexed' colour  sdeoioo,  the  colour  is  specified  by  an  index 
into  a  able  of  dirm  odour  vdues.  Seiretion  of  one  of  these  mechanisms  may  be  done  by  an  dement  in 
each  Piaure  Descriptor. 

For  Indexed*  colour  sdection.  the  COLOUR  TABLE  attribute  dement  is  provided  for  changing  the  contents 
of  the  colour  table.  ’Ibis  dement  may  appear  throughout  the  picture  bod)'.  Howeva,  the  ^ect  of  changes 
in  the  odour  able  on  any  existing  graphical  primitive  elements  that  use  the  afiected  indices  is  not  addressed 
in  this  Standard. 
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Direct  colour  model  values  are  either  a  3*tuple  or  4>uiple  of  values  providing  the  normalized  weight  of  the 
desired  colour  components.  In  the  abstract,  each  ctsnponent  is  nr-malized  to  the  continuous  range  of  real 
numbers  [0,11.  In  *  metafile,  direct  colour  model  value  compcnents  are  integers,  and  the  Metafile 
Descriptor  element,  COLOUR  VALUE  EXTENT,  allows  metafile  generators  to  specify  ti<e  minimum  and 
maximum  moafile  direa  cotour  model  values  for  normalization. 

To  the  problem  of  colour  matching  physical  devices,  the  COM  provides  a  mechanism  for  colour 

calibration.  Ute  device  ^»ce  for  a  particular  ii^uVouiput  device  consists  of  the  quantities  that  device  uses 
for  the  measurement  or  the  rendition  of  colour.  Typical  examples  of  devices  and  their  associated  device 
qacesate: 

*  colour  monitors  •  (his  space  is  the  intensities  of  the  Red.  Green,  and  Blue  phosphon; 

*  colour  film  recorders  •  this  space  is  the  Red,  Green,  and  Blue  command  values  used  for  exposing  the 
film: 

*  colour  input  scanners  •  this  space  is  the  values  measured  through  the  Red,  Green,  and  Blue  filters  of  the 
scanner; 

*  ink  jet  writers  and  thermal  printers  •  this  space  is  the  ink  values  Cyan,  Magenta,  Yellrw,  and  Black 
depuited  onto  paper. 

*  colour  printing  press  •  this  space  is  the  ink  values  which  appear  on  separation  films,  which  are  later  to 
be  rendered  on  presses  or  proofing  systems. 

For  all  the  kinds  of  devices  listed  above.  H  is  imponam  to  appreciate  that  each  of  them  has  a  well-defined 
meaning  only  in  terms  of  the  particular  device  with  which  it  is  used,  but  only  an  apjmxataie  meaning  in 
terms  of  appearance.  Fbr  example,  if  two  pictures  specified  in  terms  of  RGB  are  di^layed  on  different 
monitors,  the  colours  of  the  resulting  images  will  not  look  identical.  This  is  bwause  no  two 
monitor/display  processor  combinations  are  identical.  If  the  two  display  systems  of  the  same  space  are 
supplied  by  the  same  vendor,  the  images  can  be  close  enough  for  all  but  the  most  exacting  applications; 
nonetheless,  the  diflerence  does  exist  and  must  be  taken  inu>  accounL  Similar  considerations  hold  for  the 
input  scanner  and  ink  ^aces,  with  the  extra  problem  that  the  viewing  environment  also  affects  the 
^rpeatance. 

Calibration  is  achieved  by  the  imaging  system  convening  a  colour  in  the  specified  colour  model  to  a  colour 
in  the  reference  colour  model,  and  then  convening  to  from  the  reference  model  to  the  device  ^tace  for  its 
imaging  device.  This  applies  for  both  input  and  output  devices.  Although  this  is  conceptually  two 
operations,  it  can  be  implemented  as  one  transformation.  These  transformations  require  calibration  dau. 
The  CGM  does  not  allow  for  the  interchange  of  calibration  data.  Instead,  default  values  have  been  chosen  to 
represent  recognized  standards  for  devices  which  use  these  models. 
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Page  41 


Sub-clause  5.1:  Table  of  daia  lypc  abbrevuuons: 


Replace 

CD  Colour  Direct  Three-tuple  of  non-negative  real  values  for  red.  green,  blue  colour  sr.iaiuuci. 
with 


MD 

Model  Direct 

Three-tuple  or  four-tuple  of  non-negauve  real  values  for  ccl 
definiuon  wuhin  one  of  the  three  supported  colour  models 

CD 

Colour  Direct 

String  or  Model  Direct  (as  determined  by  CCLG' 
REPRESE.NTAT10N  METHOD). 

Pages  47-48 

Sub-eJause  5-3.7;  Replace  the  desenpuon  as  follows: 

The  precision  for  operands  of  dau  type  model  direct  (MD)  is  specified  for  subsequc.nt  dau  of  i>pe  MD  T>-t 
precision  is  defined  as  die  field  width  measured  in  uniu  applicable  lo  ihe  specific  encoding.  Aldiougf  --t 
form  of  the  parameter  is  encoding  dependent,  the  parameter  is  a  single  spccificauon  that  applies  to  cacn  or 
ail  of  the  three  or  four  components  of  parameters  of  type  C.M.  The  precisions  of  the  mdividuaJ  compcr.cr.ts 
are  not  independently  and  differently  specifiable  by  this  eicmem. 


Pages  48-t9 

Sub-clause  5J,10;  Replace  the  desenpuon  as  follows: 

The  pa.'ameiers  represent  an  extent  which  bounds  the  direct  colour  model  values  that  will  be  encour.tcrtd  i.n 
the  metafile.  It  need  not  represent  the  exact  extent  of  colour  mode!  values  contained  in  the  meuTiic 
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Subciause  5  j;  Add  the  following  .Metafile  Descnpior  Elements: 

S.3.X  COLOUR  representation  METHOD 
Parameters: 

colour  represeraaaon  method  (one  of;  RGB,  CIE  L*u*v*,CYMK,  spot  colour)  (E) 

Description: 

Four  methods  of  colour  representation  are  supported:  by  one  of  three  colour  models  (RGB,  CIE 
L*u*v*,  CYMK)  or  by  spot  colour  (names). 

Only  one  colour  represenuiion  method  may  be  used  within  a  metafile.  The  method  may  be 
defaulted  or  explicitly  set  with  the  COLOUR  REPRESENTATION  METHOD  eiement  All 
occurrences  of  coioor-seuing  elements  (AUXILIARY  COLOUR.  LINE  COLOUR.  MARKER 
COLOUR,  FILL  COLOUR.  EDGE  COLOUR.  TEXT  COLOUR)  as  well  as  the  colour  lists  of 
CPT  I-  array  and  PATTERN  TABLE  shall  be  in  the  current  method.  U  used.  COLOLU 
REPRESENTATION  METHOD  shall  be  in  the  Metafile  Descriptor,  after  BEGIN  METAFILE  and 
before  BEGIN  METAFILE  BODY. 
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Refcrcoccs: 

4.7.7 


SJJC  FONT  attributes 

PartBetcrs: 

fcni  number  (DQ 
number  of  auribute  pairs  (T) 

List  of:  pairs  of 

Anribute  type,  Auribuie  value  (S) 

where  auribuie  values  must  be  on  of: 

typ^ace  name  (S) 
fimily  name  (S) 
typeface  geneal  class  (IX) 
tyiwface  sob-class  (DO 
typeface  speciik  group  (TX) 

posture  (one  of;  postures  defined  by  ISO/EC/DIS  954 1  -5. 6.6) 
weight  (one  of;  weights  defined  by  ISO/IEC/DIS  954 1-6. 6.7) 
proportionate  width  (one  of:  see  ISO/TEC/DIS  954 l-S,  6.8) 

Description: 

The  order  of  the  attribute  values  indicates  the  relative  importance  of  the  attribute  for  font 
substitution.  A  missing  value  indicates  no  importance  to  be  placed  on  the  value.  The  following 
auribuie  types  have  been  assigned- 

typeface  name 

finnilyname 

typeface  general  class 

typefn  sub-class 

typeface  spedfic  group 

posture 

weight 

proportionate  width 

The  font  attributes  provide  a  more  detailed  descripuon  of  the  fonu  defined  in  the  FONT  LIST 
element  so  as  to  enable  rational  font  matching  in  the  event  of  the  inability  to  exactly  match  a  font 
from  the  font  name  spedfied  in  the  FONT  LIST  element. 

The  font  number  will  corre^nd  to  the  font  index  defined  in  the  FONT  LIST  elemenL 

The  typeface  name  is  the  name  of  the  font  typeface.  Note  that  a  typeface  name  implies  particular 
values  fts-  the  family  name,  weight,  posture,  and  proportionate  width. 

The  typeface  general  class  is  the  intm  general  grouping  of  fonu  with  ssmiiar  characteristics. 
Typeface  sab-classes  are  growings  that  identifies  tbe  less  general  charactetisucs  and  staru  to 
categorize  typefaces  into  similar  designs.  Typeface  specific  groups  are  typeface  ptMqjsngs  with 
very  distinet  aiJ  unique  characterigici  Typefices  cat^ionzed  to  ite  typefime  tgietdfk  gioiq>  level 
iOBrt  to  show  similar  eharacterisocs  that  ni^es  them  reasonaUy  eligible  to  be  stdstutoad  for  each 
other.  The  assigned  ftmu  groups,  and  their  auribnies.  are  defined  by  the  nonnssive  anmx  A  of 
150  9541-3. 

The  posture  of  a  font  may  be  one  of  the  following: 
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1:  upright 

2:  obliquely  slanted  clockwise  from  the  verucai.  with  no  other  design  adjustments 
3:  obliquely  slanted  counter-clockwise  from  the  venical.  with  no  other  design  adjusunents 
4;  isalic,  slanted  clockwise  and  the  design  adjusted  for  better  qtpeannee 

The  font  ««ight  is  a  measure  of  the  boldness  of  the  font.  Ass>£ri<>d  values  are: 

1:  ultra  light 
2:  extra  light 
3:  light 
4:  semi  light 
S:  medium 
6:  semi  bold 
7:  bold 
8:  extra  bold 
9:  ultra  bold 

The  proportionaie  width  ts  an  indication  of  the  rauo  of  character  height  to  charaaer  width,  and  may 
be  one  of  the  following: 

1:  ultra  condensed 
2:  extra  condensed 
3:  condensed 
4:  semi  condensed 
S:  medium 
6c  semi  expanded 
7:  expanded 
8:  extra  expanded 
9:  uloa  expanded 

In  the  preceding  list,  ultra  condensed  has  the  highest  ratio  of  character  height  to  charaaer  width, 
and  ultra  expanded  has  the  lowest  rauo  of  character  height  to  character  width. 


References: 


5J.X  FONTMETRIC  DEHNITION 

Parameters: 

font  index  (DC) 
efaaraemr  index  (Q 
left  bearing  (VDQ 
fight  bearing  (VDQ 
character  widih  (VDQ 
character  teight  (VDQ 
offsa  iron  bueUne  (VDQ 

Description: 

The  fontmetzic  infonnation  for  each  character  used  in  each  font  spedfled  is  defined  by  this  ekmenu 
If  this  elemem  is  used,  then  the  fonunetric  dau  for  each  character  uaed  in  the  metafile  must  be 
specified.  Chaiacters  not  used  by  the  metafile  may  also  be  specified,  but  are  not  required. 

References: 
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5J.X  CHARACTER  KERNING  MODE 


Parimeters: 

chaacter  kerning  mode  (one  of:  none.  pair,  sectored,  crack)  (E) 
Description: 

Defines  ibe  kerning  style,  if  any.  for  the  metafile. 
References: 


5J.X  CHARACTER  KERNING  TABLE 
Parameters: 

To  be  detennined. 

Description: 

The  dau  defined  by  this  element  will  be  dependant  upon  which,  if  any.  kerning  styles  are 
supported.  In  general,  however,  the  infonnaiion  will  be  that  which  is  required  to  kem  characten. 

References: 


5J.X  BEGIN  GLYPH  DERNITION 
Parameters: 

chaiaaer  index  (DC) 

Description:  _ 

BEGIN  GLYPH  OEFINTTION  delimits  the  beginning  of  a  definition  of  a  entity  that  will  be  ireaicd 
as  a  single  'compound  primitive*.  The  elements  that  make  up  the  compound  figure  can  be  any 
combination  of  non-closed  line  elements  such  as  POLYLINE,  CHRCnJLAR  ARC  3  POINT. 
GRCULAR  ARC  CENTRE.  ELLIPTICAL  ARC.  <ncw  curve  eiements>,  BEGIN  REQUIRED 
FEATURE,  END  REQUIRED  FEATURE,  and  CXOSE  FEATURE. 

The  figure  defined  by  the  component  line  primitives  will  form  a  character  glyph,  and  will  be 
assigned  to  the  character  code  leferenced  by  the  value  of  the  character  index  parameter. 

The  interior  of  the  ^yph  (see  4.6.4.4)  is  lilted  according  to  the  current  fiHed-area  attributes.  The 
comptnite  figure  will  be  either  a  single  figure  or  a  set  of  figures,  which  is  filled  according  to  the 
pviiy  (odd  or  even)  algorithm  described  under  the  POLYGON  element,  with  the  exception  that  the 
Bansiticm  fiom  a  venex  mvked  as  a  'closure  vertex’  to  the  next  poiiu  specified  in  the  definition 
does  not  cwmintte  a  boundary  to  the  fill  algorithm.  A  vertex  is  irtariced  as  a  'closure  venex'  by  the 
use  of  the  CLOSE  CONTOUR  etemem. 

The  individual  figures  of  the  set  are  not  filled  individually.  The  figures  in  the  set  may  be  disjoint 
(as  in  the  'dot'  in  the  letter  '0,  may  create  lioles'  (as  in  the  interior  of  the  letter  'o’),  or  may 
overlap. 

References: 
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SJ.X  END  GLYPH  DEFINITION 


Parameters: 

None 

Description: 

END  GLYPH  DEFINITIOPN  delimits  the  end  of  a  compound  outline  definiuon  of  a  character 
glyph. 

References: 


5J.X  BEGIN  REQUIRED  FEATURE 
Parameters: 

None 

Description: 

BEGIN  REQUIRED  FEATURE  delimits  the  beginning  of  a  definition  of  a  entity  that  will 
treated  as  a  single  'compound  primitive'.  The  elemenu  that  make  up  the  compound  figure  can 
any  combination  of  non-closed  line  elemenu  such  as  POLYLINE.  CIRGJLaR  ARC  3  POINT. 
CIRCULAR  ARC  CENTRE.  ELLIPTICAL  ARC.  CLOSE  CONTOUR,  and  <new  cur^e 
elements>.  The  Hgute  may  be  a  disjoint  figure. 

If  used,  BEGIN  REQUIRED  FEATURE  shall  occur  within  the  scope  of  a  BEGIN  GLYPH 
DEFINITION  block.  The  resulting  composite  figure  will  be  a  specific  feature  of  the  character 
glyph  being  defined  which  is  required  for  proper  rendenng  of  the  gl>ph  (such  as  a  seriO. 

References: 


SJ.X  END  REQUIRED  FEATURE 
Parameters: 

None 

Description: 

END  REQUIRED  FEATURE  delimiu  the  end  of  a  compound  outline  definition  of  a  specific 
feauire  of  a  character  glyph  required  fu’  proper  rendering  of  the  gl>ph. 

References: 


5J.X  CLOSE  CONTOUR 
Parameters: 

None 

Description: 

CLOSE  CONTOUR  deiimiu  the  end  of  a  compound  outline  of  a  character  glyph.  The  last  point 
spediled  is  marked  as  a  'closure  vertex  '. 

References: 


95 


STfT 


Page  55 


SutHrlause  5A2,  first  paragraph  of  desaipiion; 

Quinge  'red,  green,  and  blue*  into  'direct* 

Page  57 

Sub-clause  5.4.7.  first  line  of  second  paragraph  of  description: 

Change  "KCB"  into  *a  direct  colour  value* 

Page  60 

Subclause  5  J:  Add  the  following  Conuol  Elemenis: 

5.5.x  BEGIN  COMPOUND  LI-NE 
Parameters: 

None 

Description: 

BEGIN  COMPOUND  LIN^  delimits  the  beginning  of  a  definiiion  of  a  entity  that  will  have 
consistent  line  attributes  and  will  be  treated  as  a  single  ’compound  primitive*.  Ibe  elements  that 
make  up  the  compound  line  can  be  any  combination  of  non-closed  line  elements  such  as 
POLYLINE.  CIRCULAR  ARC  3  POINT.  QRCULAR  ARC  CENTRE,  ELLIPTICAL  ARC.  or 
<new  curve  elements^. 

References: 


5J.X  END  COMPOUND  LINE 
Parameters: 

None 

Description: 

END  COMPOUND  LIN^  delimits  the  end  of  a  compound  line  definition. 

References: 


5JJC  BEGIN  TEXT  PATH 
Parameters: 

Mnn_a 

none 

Description: 

BEGIN  TEXT  PATH  delimits  the  beginning  of  a  definitioi  (MT  a  entity  that  wiU  provide  the  path 
in  which  a  text  string  will  be  drawn.  The  elcmenu  that  make  up  the  compound  text  path  can  be 
any  combination  of  non-closed  line  elemenu  such  as  POLYLINE,  DISJOINT  POLYLINE. 
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CIRCULAR  ARC  3  POINT.  CIRCULAR  ARC  CENTRE.  ELLIPTICAL  ARC,  or  <new  curve 
elements>. 

Once  delined.  the  compound  text  path  takes  the  place  of  the  text  path  as  defined  by  the  TEXT 
PATH  element  and  the  CHARACTI:;  ORIENTATION  elements.  TTie  skew  of  the  characters  is 
sun  relative  to  that  specified  in  the  CHARACTER  ORIENTATION  dement,  but  the  placement  of 
subsequent  characters  is  along  the  compound  text  path  instead  of  in  a  line  along  the  character  up 
vector  or  character  base  vector. 

References: 


END  TEXT  PATH 
Parameters: 

None 

Description: 

END  TEXT  PATH  ddimits  the  end  of  a  compound  text  path  definition. 

References: 


SJJi  BEGIN  CUP  REGION 
Parameters: 

None 

Description: 

BEGIN  CLIP  REGION  ddimits  the  beginning  of  a  definition  of  a  entity  that  will  provide  the 
clipping  region.  When  CLIP  INDICATOR  is  'on’  only  the  portions  of  graphics  dements  inside  car 
tm  the  boundary  of  the  clipping  region  att  drawn.  The  dements  that  nuke  up  the  clipping  region 
can  be  any  combination  of  closed  or  non-dosed  dements  such  as  POLYLINE,  DISJOINT 
POLYLINE,  POLYGON.  POLYGON  SET.  CIRCULAR  ARC  3  POINT.  CIRCULAR  ARC  3 
POINT  CLOSE.  ORCULAR  ARC  CENTRE.  CIRCULAR  ARC  CENTRE  CLOSE, 
ELLlPnCAL  ARC  CLOSE,  or  <new  curve  dements>.  The  entity  thus  defined  is  essentially  a 
closed  figure  whose  boundary  is  used  as  thecli{q)ing  boundary. 

Once  defined,  the  dipping  region  takes  the  place  of  the  clipping  region  defined  in  CLIP 
RECTANGIX. 

References: 


5Ja  END  CUP  REGION 

Parameters: 

- 

none 

Description: 

END  CUP  REGION  ddimiu  the  end  of  a  clipping  region  definition. 

References: 
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5JJC  BEGIN  SHIELD  REGION 


Parameters: 

None 

Description: 

BEGIN  SHIELD  REGION  delimits  the  beginning  of  a  definition  of  a  entity  that  win  provide  the 
shielding  region.  When  SHIELD  INDICATOR  is  'on'  only  the  portions  of  graphics  elements 
outside  ^  the  shielding  region  are  drawn.  The  elements  that  make  up  the  shielding  region  chn  be 
ary  conbinaiion  of  closed  or  non>closed  elemenu  such  as  POLYLD^  DISJOIN  POLYLINE. 
POLYGON.  POLYGON  SET.  CIRCULAR  ARC  3  POINT.  CIRCULAR  ARC  3  POINT 
CLOSE,  CIRCULAR  ARC  CENTRE,  CIRCULAR  ARC  CENTRE  CLOSE,  ELLIPTICAL 
ARC  CLOSE,  or  <new  curve  elements>.  'Tbe  entity  thus  is  essentially  a  closed  figure 

whose  boundary  is  used  as  the  shielding  boundary. 

References: 


5.5.x  END  SHIELD  REGION 
Parameters: 

None 

Description: 

END  SHIELD  REGION  delimits  the  end  of  a  shielding  region  dcfiniuon. 
References: 


5J.X  SHIELDING  INDICATOR 
Parameters: 

shield  indicator  (one  of:  off,  on)  (E) 

Description: 

Wh»  SHIELD  INDICATOR  is  'off.  shielding  of  graphical  primitive  elements  is  not  required. 

When  SHIELD  INDICATOR  is  'on',  only  those  portions  of  graphical  primitive  elements  outside 
of  the  shielding  region  are  drawn. 

References: 


5,5.x  nUNG  MODE 

Parameters: 

tiling  mode  (one  of:  off^m)  (E) 

Description: 

When  TILING  MODE  is  'off.  subsequem  COMPRESSED  PEL  ARRAY  elemenu  are  to  be 
aeaied  as  independent  images  displayed  per  the  corresponding  PEL  ARRAY  ORIENTATION  and 
PEL  ARRAY  DIMENSIONS  attribute  elements,  and  positioned  in  VDC  space  via  the  PEL 
ARRAY  REFERENCE  POINT  element. 
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When  the  TILING  MODE  is  *on'.  each  subsequent  COMPRESSED  PEL  ARRAY  dement  is 
treated  as  a  single  tile  in  a  tiled  image  and  indexed  by  the  Pd  Anay  Identiiier  parameter.  The  PEL 
ARRAY  ORIENTATION  and  PEL  ARRAY  DIMENSIONS  elements  describe  the  sizing  and 
orientation  of  the  entire  tiled  image.  The  dimensional  information  for  the  tiles  in  the  image  is 
contained  in  the  TILED  PEL  ARRAY  element. 

References: 


Page  68 

Sub-clause  5.6.9:  Add  the  following  at  the  end  of  the  third  paragraph  of  the  description: 
Note  that  COLOUR  PRECISION  only  applies  to  direa  colour  modd  values. 


Page  77 


Subclause  5.6:  Add  the  following  Graphical  Primitive  Elements: 

5.6.x  CONIC  ARC 

Parameters: 

Stan  point  (P) 
end  point  (p) 

A3.CJ)£  J  {6R) 

Description: 

A  conic  arc  is  drawn  which  is  defined  as  follows; 

A  conic  arc  is  defined  by  the  end  points  and  the  six  parameters.  The  conic  arc  itsdf  is  defined  by 
the  six  parametere  in  the  following  equation; 

ACXh  *  BXvYv  ♦  C(y2)  ♦  DXv  EYv  ♦  F  -  0 

where  (Xv.Yv)  are  the  horizontal  and  vertical  axes,  respectively,  of  VDC  space.  In  order  for  the 
conic  arc  to  be  processed  correctly  by  the  receiving  system  given  the  above  representauon,  the 
conic  arc  entity  must  be  positioned  su^  that  each  of  its  axes  is  paraild  to  dther  the  Xv  axis  or  Yv 
axis.  The  arc  is  then  positioned  correctly  in  VDC  space  by  using  the  value  of  the  CONIC  ARC 
transformation  MATRDC  element 

To  determine  the  form  of  the  conic  arc,  the  quantities  Ql,  Q2  and  Q3  are  defined  as  follows: 


1  A 

B/2 

D/21 

Q]  a  determinant  of 

IB/2 

C 

E/2! 

ID/2 

E/2 

F  1 

Q2  ■  determinant  of 

1  A 

IB/2 

B/21 
C  1 

Q3-A  +  C 

U  Q2>0  and  (Q1*Q3}<0,  then  the  arc  is  an  dlipse. 
If  Q2<0  and  QloO.  then  the  arc  is  a  hyperbola. 

If  Q2«0  and  QloO.  then  the  arc  is  a  p^bola. 
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In  the  case  where  the  conic  arc  is  elliptical,  to  distinguish  the  arc  in  question  from  its  complement, 
the  direction  of  the  arc  with  lespea  to  the  deTinition  space  must  be  from  start  point  to  end  point  in 
a  counterclockwise  direction. 

In  the  case  where  the  conic  arc  is  parabolic  or  hyperbolic,  the  parameterization  defines  a  unique 
portirn  of  the  parabola  or  a  unique  portion  of  a  branch  of  the  hypertr  !a,  thus  the  direction  is 
BielevanL 

Tlie  direction  of  the  conic  arc  with  respect  to  VDC  space  is  determined  by  the  original  direction  of 
the  arc  in  definition  space,  in  conjunction  with  the  action  of  the  CONIC  ARC 
niANSFORMATION  MATRIX  element 

ScfercBces: 

4. 


5.6.x  CONIC  ARC  TRANSFORMATION  MATRIX 

Parameters: 

matrix  elements 

if  the  VDC  type  is  'integer', 

Rlljll2Jil3Jl21Jl22Jl23  (61) 

if  the  VDC  type  is  ’real’, 

RllJll2Jll3JUlJl22jl23  (6R) 

Description: 

Hus  element  is  intended  to  work  in  conjunction  with  the  CONIC  ARC  element  to  transform  the 
conic  arc  to  iu  final  position  and  orientation  in  VDC  space.  ’The  Transformation  Matrix  enuty 
transforms  the  defining  point  coordinates  by  means  of  a  matrix  multiplication.  ’This 
transformation  is  achieved  by  ^plying  the  matrix  multiplication  to  the  coordinates  of  the  conic 
sc. 

The  notation  for  this  transformation  is  follows: 

IRll  R12R13I  IXinI  -  IXoutI 
I  R21  R22  R23I  I  Yin  1  I  Yout  I 
I  II 

where  IRijI  is  the  transformation  matrix.  (Xin,Yin)  is  the  coordinate  to  be  transformed,  and 
(XouLYout)  is  the  coordinate  resulting  from  the  transformation.  Both  the  input  and  output 
coc/dinaie  systems  are  assumed  to  be  onhogonal,  canesian  and  right-handed. 

References: 

4. 


5.6.x  PARAMETRIC  SPLINE  CURVE 

Parameters: 

«rve-»ype  (PO 

H-degree  of  cominmiy  (1) 

N-number  of  segmenu  (I) 

T-break  pi^  list  for  polynomial  ((N+DR) 
X  coordinate  polynmnial  list  (N  sets  of  four) 
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AX JX,CXJ)X  ((N«4)R) 

Y  coordinate  polynomial  list  (N  sets  of  four) 

AY3Y.CYJ>Y  ((N*4)R) 

Description: 

The  parametric  curve  to  be  drawn  is  delined  as  follows; 

The  parametric  spline  curve  is  a  sequence  of  parametric  polynomial  segmenu.  The 
parameterization  shown  above  is  generalized  to  allow  for  the  represenution  of  many  different 
parametric  spline  curves  using  this  one  element  The  curve.type  parameter  indicates  the  type  of 
parametric  curve  as  it  was  rqnesented  in  the  sending  system  before  being  convened  to  this  generic 
fonn.  The  following  curve  v^tks  have  been  assigned: 

1:  linear 
2:  quadratic 
3:  cubic 

4:  Wilson*Fow!er 
5:  modified  Wilson-Fowler 
6:  B'Spline 

Values  above  6  are  reserved  for  registration  and  future  standardization,  and  negative  values  are 
available  for  implementation-dependent  use. 

The  degree  of  continuity  parameter.  H.  indicate  the  smoothness,  or  continuity  of  the  curve  with 
respea  to  arc  length.  If  H«0,  the  curve  is  .  ..irtuous  at  all  break  points.  If  H*!,  the  curve  is 
continuous  and  has  slope  continuity  at  all  break  poinu.  If  the  curve  is  continuous  and  has 
both  slope  and  curvature  continuity  at  all  break  points. 

The  number  of  segmenu  parameter,  N,  is  the  number  of  polynomial  segmenu  to  be  used  to  define 
the  curve.£ach  segment  is  defined  by  a  cubic  polynomial  in  X  and  Y  that  is  evaluated  using  the 
eight  polynomial  coefficienu  associated  with  that  segment;  Ax.Bx.CxJ)x,Ay,By,CyJ)y.  Segment 
i  is  delimited  by  iu  knou,  T(i)  and  T(i+1). 

The  parametric  spline  curve  is  displayed  with  the  current  line  attributes. 

References: 

4. 


5.6.x  RATIONAL  B-SPUNE  CURVE 

Parameters: 

K'Upper  index  of  sum  (I) 

M-degree  of  the  basis  function  (1) 
eqoation.type  fiag  (one  of:  rational,  polynomial)  (E) 

T'knca  sequence  list  ((K+M+  1)R) 

W-weightlist  ((K+I)R) 
control  point  list  ((K-^1)P) 
stanjwamxndjauam  (2R) 

Description: 

A  two  dimensional  rational  B-spline  curve  is  drawn.  The  realization  of  this  element  is  based  upon 
the  Pational  B*Spiine  Curve  entity  of  IGES  V3.0.  The  specfitcatitms  are  identical  except  that  the 
curve  is  constrained  u>  two  dimensions,  i.e.  the  Z  Polynomial  is  assumed  to  be  zero  (0). 
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Valid  values  of  die  upper  index  and  degree  paiameieis  are  non-negative  integers. 

Valid  values  of  the  control  points  are  such  that  no  two  adjacent  points  are  coincident. 

If  all  of  the  weights  in  the  weight  list  W  are  not  equal,  then  the  equation.type  flag  is  set  to 
Rational,  otherwise  the  equationjype  Oag  is  set  to  Polyr  imial. 

References: 

4. 


5.6.x  COMPRESSED  PEL  ARRAY 
Parameters: 

FID-pel  array  identifier  (I) 

T-eacoding  type  (one  of;T4,T6XZW,  Bitmap,  null  background,nul]  foreground)  (E) 

P-ptl  path  (one  of:0,90,l 80,270)  (E) 

L-line  progression  (one  of:90,270)  (^ 

S-pel  spacing  (VOQ 
spacing_iauo  (R) 

N*number  of  pels  per  line  (I) 

NL-number  of  lines  (I) 
pelamy  (BS) 

Description: 

A  compressed  pel  array  image  is  defined  as  follows; 

The  pel  array  identifier,  PID,  is  used  as  the  tiling  index  when  Tiling  Mode  is  ON.  When  the 
Tiling  Mode  is  OFF,  the  PIO  is  used  as  an  identiner  to  uniquely  label  the  pel  array  for 
manipulation  or  access  purposes. 

The  encoding  type  parameter,  T,  specifies  the  compression  format  used  to  encode  the  image.  If  T 
is  specified  as  '14'',  the  image  is  encoded  according  the  one  or  two  dimensional  scheme  defined  in 
CCITT  Recommendation  T.4  (Group  3  facsimile).  If  T  is  Tb*,  the  image  is  encoded  according  to 
the  two  dimensional  scheme  defln^  in  CCITT  Recommendation  T.6  (Group  4  CKsimile).  T 
^lecified  as  "null  background’  or  ’null  foreground*  is  used  mainly  when  in  tiling  mode  to  indicate 
that  all  pels  in  the  tile  are  known  to  be  b^ground  or  foreground  and  the  tile  has  no  encoded 
content  If  either  of  these  are  specified,  then  the  Pel  Amy  itself  will  be  a  zero  length  or  ’null" 
binary  string. 

The  pel  path  parameter,  P,  is  the  direction  of  progression  of  successive  pels  akmg  a  line  relative  to 
the  VDC  X  axis.  This  parameter,  in  conjunction  with  the  pel  qadng.  S,  and  the  number  of  pels 
per  line,  N,  implicitly  define  the  line  position,  length  and  granularity  for  each  line  in  the  decoded 
pel  amy.  The  spacing.iatio  is  defined  as  the  ratio  M/S,  where  M  is  the  distance  in  VDC  units 
between  two  successive  lines  a(  pels,  and  S  is  the  Pc'  Spacing,  which  is  the  distance  in  VDC 
between  two  adjacent  pels  in  a  lin&  hkne  that  even  if  the  VDC  TYPE  is  Integer,  the  values  of  the 
M  Spadng  S  and  the  line  spacing  M  will  be  of  type  Real 

The  line  progression  parameter,  L.  is  the  direction  of  progression  oi  successive  of  pel  lines  and  is 
expressed  as  a  direciion  relative  to  P.  L.  in  conjutKtion  with  the  spacing_imio  and  the  number  of 
liii^  NL.  implicitly  defines  the  size  of  the  decoded  image  m  the  direciion  of  L.  The  line  spacing 
(LS)  of  the  liM  of  pels  can  be  determined  as  follows: 

LS  ■  spadngjatio  *  S 

The  pel  amy  iisdf  is  sttaed  in  either  of  the  formats  defined  by  T,  encoded  as  a  bit.stream. 
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References: 

4. 


5.6.x  TILED  PEL  ARRAY 

Parameters: 

TID^ed  pdanay  ID  (I) 

TD^iled  ^  anay  dimensions  (21) 

NP-number  of  {wls  per  tile  line  Q 
NL'Oumber  of  lines  per  tile  (1) 

TO-tiling  oltsci  (21) 

Description: 

A  tiled  pel  anay  image  is  defined  as  follows: 

The  tiled  pel  anay,  TTD,  uniquely  identifies  the  tiled  image.  Valid  values  of  this  ID  are  positive 
integers. 

The  tiled  pel  array  dimensions  parameter,  TD.  consists  of  two  positive  integers  corresponding  to 
the  number  of  tiles  in  the  direction  of  the  Pel  Path  and  Line  Progression  parameters,  respectively, 
of  the  PEL  ARRAY  ORIENTATION  element.  Multiplying  the  two  TD  integers  together  will 
give  the  total  number  of  tiles  contained  in  the  tiled  image. 

The  number  of  pels  per  tile  line  parameter,  NP,  specifies  the  tile  dimension  in  units  of  Pei 
Spacing  found  in  the  PEL  ARRAY  DIMENSIONS  element,  in  the  Pel  Path  direction  of  the  PEL 
ARRAY  ORIENTATION  element,  for  each  tile  of  the  tiled  image. 

The  number  of  lines  per  tile  parameter,  NL,  specifies  the  tile  dimension  in  units  of  line  spaces, 
derived  from  the  Spacing  Ratio  of  the  PEL  ARRAY  DIMENSIONS  element,  in  the  Line 
Progression  direction  of  the  PEL  ARRAY  ORIENTATION  element,  for  each  tile  of  the  tiled 
image. 

The  tiling  offset  parameter,  TO,  speciRes  the  location  of  the  pel  array  image  within  tiling  space  by 
defining  the  offset  of  the  first  pel  of  the  pel  array  from  the  PEL  ARRAY  REI=ER£NC£  POINT. 
The  offset  is  specified  by  two  positive  integers  corre^nding  to  the  number  of  pel  spacu  in  the 
Pel  Path  direction  and  line  spaces  in  the  Line  Progression  direction,  respectively. 

References: 


5.6.x  IMAGE  APERTURE 
Parameters: 

X1.Y1X1,Y2  (40 
Description: 

The  dement  defines  the  rectangular  area  of  peb  in  the  decoded  pd  array  that  is  to  appear  in  the 
metafile  picture.  This  dement  should  immediately  precede  the  Pd  Anay  dement  to  which  it 
aigiiies,  as  this  dement  win  affea  all  subsequent  Pd  Amy  etemems  until  another  Image  Aperture 
is  expUdtly  defined. 

The  four  integers  form  two  coordinate  pairs.  (Xl.YI)  and  (X2,Y2)  corresponding  to  the  first  and 
last  pels  to  appear,  respectively,  where  X1<«X2  and  Yl<aY2.  Fbr  example,  (6j)  would  specify 
the  seventh  in  line  3.  given  that  (0,0)  spedfles  the  first  pel  on  the  first  line. 
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These  two  comer  pels.  (Xl.Y  1)  and  (X2,y2).  -define  the  rectangular  portion  of  interest  of  the  Pci 
Array  image  to  be  positioned  in  the  metafile  \  >re.  The  first  pel  deftned  by  (Xl.Yl)  above  is  to 
be  positioned  at  Ute  reference  point  of  the  Per  Array  element,  with  the  remainder  of  the  image 
realized  as  per  the  Pel  Spacing.  Spacing  Ratio.  Pel  Path,  and  Line  Progression  pararneters  of  the 
Pel  Array  element  Valid  values  of  the  IMAGE  APERTURE  parameters  are  non-negative  integen. 

References: 

4. 


PEL  ARRAY  REFERENCE  POINT 
Parameters: 

leferencejioint  (P) 

Description: 

The  pel  array  reference  point  defines  the  position  of  the  upper  left-hand  comer  of  the  pel  array 
element  to  be  displayed.  If  the  pel  path  and  line  progression  are  thought  of  as  vectors,  the  upper 
left-hand  comer  is  defined  as  point  of  origin  for  the  two  vectors. 

References: 

4. 


5.6.x  BOXED  TEXT 
Parameters: 
two  points  {2P) 

flag  (one  of:  not  final,  final)  (E) 
string  (S) 

Description: 

The  two  points  spectfled  represent  diagonally  opposite  comers  of  a  rectangle  oriented  parallel  to  the 
VDC  axes.  BOXED  TEXT  behaves  as  does  fEXT,  with  the  exception  that  the  text  is  constrained 
to  be  within  the  rectangle  defined  by  the  two  points. 

The  character  codes  specified  in  the  siring  are  interpreted  to  obtain  the  associated  symbols  from  the 
currently  setoed  character  set  Characten  are  displayed  on  the  view  sir'ace  as  spewed  by  the  tex; 
aoribuies.  Fonnai  effector  control  characters  (such  as  CR,  LF,  BS.  HT,  VT,  and  are  permiued 
in  a  string  but  their  intexpretation  is  impiemeniation  dependenu  Control  characters  used  for 
character  set  invocation  and  designation  (SL  SO,  ESC  SS2,  and  SS3)  are  permitted  according  to 
the  setting  of  CHARACTER  CODING  ANNOUNCER. 

Tlie  characten  are  (BmcBBoncd  according  to  the  height  and  width  of  the  bounding  box  and  are 
oriented  according  to  CHARACTER  ORIENTATION.  The  directiim  of  character  placement  in  the 
string  relative  to  CHARACTER  ORIENTATION  is  according  to  TEXT  PATH. 

All  text  in  the  string  is  displayed  whhm  the  spedlied  bounding  box.  If  necessary,  the  values  of  the 
text  attributes  CHARACTER  HEIGHT.  TEXT  PRECSION,  and  TEXT  FONT  INDEX  which  are 
used  to  display  the  string  are  varied  to  force  the  text  to  conipietely  flU  the  bounding  box. 

The  flag  parmeter  is  used  to  permit  changing  the  following  text  attributes  and  control  elements 
within  a  siring  which  will  be  aligned  as  a  single  block:  TEXT  FONT  INDEX,  TEXT 
PREaSlON,  CHARATER  EXPANSION  FACTOR,  CHARACTER  SPACING.  TEXT 
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COLOUR.  CHARACTER  HEIGHT.  CHARACTER  SET  INDEX.  ALTERNATE  CHARACTER 
SET  INDEX,  TEXT  BUNDLE  INDEX.  AUXBJARY  COLOUR,  mi  TRANSPARENCY - 

If  the  flag  u  sex  to  ‘not  final',  Uie  character  cxxka  in  the  sihng  taramaer  are  accumuUted.  along 
with  the  carnsu  aicibute  seuings.  In  ihia  case,  only  the  auhbute  seoxng  ekmems  lisxed  above  are 
allowed  between  dus  element  jid  the  APPEND  TEXT  element  With  the  eiceputm  of  the 
escape,  no  other  metafile  ekmenis  of  any  type  are  allowed.  ESCAPE  is  permiued  but  has  no 
sandatdtzadeflecL 

If  the  flag  is  set  to  'final',  the  string  parameter  corstiuiies  the  endre  string  to  be  delayed.  It  is 
dtis  rffi«*T***^  smnt  to  which  the  text  bound  box  applies.  The  potaioa  the  string  is  detereuned 
by  the  >K«nd'»g  box.  Text  eletnenu  with  a  null  sring  parameter  art  kgil  and  may  be  followed  by 
the  allowed  teat  atshbotes  and  APPEND  TEXT  as  described  above. 

NOTE-  TEXT  PRECISION  is  included  in  the  ataibutes  which  may  be  changed  to  achieve  the  teat 
resihcuoa  begtmw*-  TDCT  PRECISION  cenirois  the  relationship  between  cortentJy  set  values  of 
text  aohbuies  and  the  valims  actually  used  for  display  of  a  string  (the  ‘reaiixed*  vali»»).  The 
realization  of  the  text  restriction  required  by  the  BOX^  TEXT  elements  may  mandtue  artotha 
oupping  from  requested  to  realize  attribute  values  tlum  would  be  allowable  under  the  current  TEXT 
PRQSION.  Hence  the  requiremems  of  the  current  TEXT  PREQSION  may  have  to  be  ignored  to 
achieve  the  proper  display  of  the  BOXED  TEXT  ekment. 

When  the  flag  is  'not  final'  this  element  causes  a  state  uansition  in  the  suie  dugram  of  figure  12. 
into  the  PARTIAL  TEXT  sute. 

References: 

4. 


S.6.X  PATH  TEXT 
Parameters: 

flag  (one  of;  not  final,  final)  (E; 

«ring  (5) 

Description: 

The  PATH  TEXT  element  shall  be  immediately  preceded  by  a  compound  line  definition.  The 
alignment  point  of  the  siring  will  be  a  point  along  the  delink  text  path  corresponding  to  the 
ctorent  TEXT  ALIGNMENT  value. 

the  duncter  codes  specified  in  the  suing  are  interpreted  to  obtain  the  associated  symbols  from  the 
cmrently  selected  character  set.  CharactcnaredtqtlayedaatheviewsuiiKeasspe^iedby  thetext 
attributes.  Fonnat  effector  oontrol  diaraciers  (such  as  CR.  IF,  BS.  HT,  VT.  and  FF)  am  permiued 
in  a  string  but  their  isterpretaiion  is  implemeniaiitm  dependent.  Control  characters  used  for 
character  se  invocation  and  designatioa  (SI.  SO.  ESC.  SS2,  and  S53}  $n  permitted  according  to 
the  setting  of  CHARACTER  CODING  ANNOUNCER. 

The  characten  are  dimensioned  according  to  the  CHARACTER  HEIGHT  and  CHARACTER 
EXPANSION  FACTOR  and  are  oriented  according  to  CHARACTER  ORIENTATION.  The 
direnion  of  character  placement  in  the  string  ndadve  to  CHARACTER  ORIENTATION  is  along 
the  path  defined  within  the  n>pe  of  the  precedtag  BEGIN  TEXT  PATH  and  END  TEXT  PATH 
elements.  If  the  string  length  exceeds  the  length  of  the  path,  the  characten  of  tbe  string  will 
to  be  placed  alone  the  path  defined  by  a  vector  wheat  tail  a  the  last  point  of  ite  path  and 
whose  dfreokm  is  the  dveoion  of  the  path  at  the  last  poinL 

The  flag  parameter  is  used  to  permit  changing  the  following  text  attributes  and  cmurol  elements 
within  a  string  which  will  be  aligned  as  a  single  block;  TEXT  FONT  INDEX.  TEXT 
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PRiaSION.  CHARAHER  EXPANSION  FACTOR,  CHARACTER  SPACING.  TEXT 
COLOUR,  CHARACTER  HEIGHT.  CHARACTER  SET  INDEX.  ALTERNATE  CHARACTER 
SET  INDEX  TEXT  BUNDLE  INDEX.  AUXILIARY  COLOUR,  md  TRANSPARENCY 

If  ibe  Clai  a  set  to  MX  daal'.  ilw  duncia  codes  m  the  stmg  pmtama  m  acxumuUusd,  siong 
wttb  the  cuiTcnt  suriNite  seuings.  la  this  case,  only  the  sunbwe  scumi  etemoas  listed  juve  jut 
allows  between  this  element  and  the  APPEND  TEXT  etonent  With  the  atcejnton  of  the 
ESCAPE,  no  odter  metafile  elements  of  any  type  are  allowed.  ESCAPE  is  permitted  bus  has  no 

If  the  flag  is  set  to  tinal'.  the  suing  paneneter  the  entire  string  to  be  ^sj^yed.  It  is 

this  ccoiplete  string  to  which  the  ten  bo«md  boot  apgrfiei.  The  position  of  the  rering  it  determined 
by  the  boondi]^  box.  Text  ekmou  with  a  null  string  panmeser  are  legal  and  may  be  followed  b> 
the  allowed  text  attributes  and  APPEND  TEXT  at  described  above. 

NOTE*  When  the  flag  is  'not  final'  this  dement  causes  a  xuu  transiuon  m  the  state  diagram  of 
figure  12,  into  the  PARTIAL  TEXT  state. 

References: 

4. 


5.6.x  RESTRICTED  PATH  TEXT 
Parameters: 

flag  (one  of:  not  (Inal,  final)  (E) 
string  (S) 

Description:  _ 

The  RESTRICTED  PATH  TEXT  behaves  as  docs  PATH  TEXT,  with  the  exception  that  the  lexi 
is  constrained  to  be  the  same  length  as  the  path  along  which  it  is  to  be  drawn. 

The  charaoiT  codes  specified  in  the  string  arc  interpreted  to  obuun  the  associated  symbols  from  the 
catrentiy  selected  character  set.  Characten  are  displayed  on  the  view  surface  as  spotted  by  the  text 
attributes.  Fmmat  eflector  control  characters  (such  as  CR.  LP.  BS.  HT.  VT.  and  FF)  are  permiued 
in  a  siring  but  their  interpretation  is  implementation  dependem.  Control  characters  used  for 
character  set  invocation  and  designation  (SI.  SO.  ESC  ^2.  and  SS3)  are  permitted  accmdmg  to 
the  setting  of  CHARACTER  CODING  ANNOUNCER. 

The  characters  are  dimensioned  according  to  the  CHARACTER  HEIGHT  and  CHARACTER 
EXPANSION  FACTOR  and  are  oriented  according  to  CHARACTER  ORIENTATION.  The 
direction  of  character  placement  in  the  string  relative  to  CHARACTER  ORIENTATION  is  along 
the  path  defined  within  the  scope  of  the  preceding  BEGIN  TEXT  PATH  retd  END  TEXT  PATH 
elements. 

AU  text  in  the  sring  is  displayed  along  the  specified  COMPOSITE  TEXT  PATH.  If  necessary, 
and  only  if  necessary,  the  values  of  the  text  attributes  CHARACTER  HEIGHT.  CHARACTER 
expansion  FACTOX  character  SPAONC.  text  precision,  and  TEXT  FONT 
INDEX  winch  ree  toed  to  display  the  saing  are  varied  to  force  the  text  to  be  the  sreiw  length  as  the 
defining  compo^  path.  It  is  only  the  reaJixed  values  of  these  retribines.  ared  to  display  this 
ringie  saing.  which  are  varied.  The  method  ttf  varying  the  atadtates  is  anptancataiian  dqrendent 

The  flag  preameter  is  used  to  permit  changing  the  foUowing  text  ataihtmtf  and  control  dements 
within  a  saing  which  will  be  aligned  as  a  single  block:  TEXT  FONT  INDEX.  TEXT 
PREOSION.  CHARATER  EXPANSION  FACTOR.  CHARACTER  SPAONG.  TEXT 
COLOIJR.  character  HEIGHT.  CHARACTER  SET  INDEX.  ALTERNATE  CHARACTER 
SET  INDEX.  TEXT  BUNDLE  INDEX,  AUXILIARY  COLOUR,  reid  TRANSPARENCY. 


* 
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If  die  flag  u  set  to  iKM  fiiiai'.  lix  duuracter  codes  in  the  sorsig  panmetcr  accumuiued.  aiong 
with  the  cumau  aiihbute  seuings.  In  ihu  case,  only  die  aunbute  setung  idcmems  listed  above  arc 
aUowed  bewreeu  this  ekmeat  and  the  APPEND  TEXT  eJemem.  Witb  ibe  eaecjHtwt  of  ibe 
ESCAPE,  00  other  metafile  elements  of  my  type  wt  allowed.  ESCAPE  a  permnaKl  b«i  has  no 

mrvlimirtrri  rjtm 

U  the  (lag  is  set  to  Ttaal'.  the  string  parameter  consutuus  the  enure  suing  u>  be  di^ycd.  !t  a 
this  complete  string  to  which  the  leu  bound  box  appbes.  The  posmon  of  the  smug  a  desesTtuned 
by  the  bounding  boot.  Tendemenu  wuh  a  nuU  string  pansMter  are  legjU  and  may  be  foUowcd  by 
die  aikiwed  tm  aoribuies  and  AFPE>n[}  TEXT  » tktaribed  above. 

NOTE-  TEXT  PREOSION  is  included  m  the  aarfbota  which  may  be  cb^gtd  to  achieve  the  sexi 
rattnetkm  becaaise  TEXT  PRECISION  controls  the  reJatioiuhip  between  ctnrendy  set  values  of 
text  anrihutes  and  the  values  aouaily  used  for  display  of  a  string  (the  'lealixed*  values).  The 
feaiixation  <rf  the  tot  resthetion  required  by  the  RESTRICTED  PATH  TEXT  elemenu  may 
mandate  another  mapping  from  requested  to  roiue  aunbute  values  than  would  be  allowable  under 
the  citrreat  TEXT  PROSION.  Hence  the  rtquiremenu  of  the  current  TEXT  PRECISION  may 
have  to  be  ignored  to  achieve  the  ^oper  display  of  the  RESTRICTED  PATH  TEXT  elemcrsL 

When  the  (lag  is  not  faui'  this  element  causes  a  sute  transiuon  in  the  sate  diagram  of  figure  !2. 
into  the  PARTIAL  TEXT  sute. 

References; 

4. 


Page  95 

Sulxlause  5.7J2;  Add  ihe  following  at  the  end  of  the  third  paragraph  of  the  desenpuon: 
Note  that  COLOUR  PRECISION  only  applies  lo  direct  colour  mode!  values 

Page  97 

Subclause  S.7:  Add  the  following  auribuie  elements: 


5.7 Jt  LINE  TYPE  OEHNITION 
Parameters: 

UnetypefDO 

dash  unit  selector  (one  of;  VDC.  mm,  nabve  device  units,  abstract)  (E) 

dash  repeat  length  (R) 

adaptive  (lag  (ooe  of:  no.  yes)  (E) 

list  ttf  dash  ekmems  (nl) 

Description: 

This  eiement  defines  a  linetype  and  associaun  it  with  an  index  for  future  reference.  Parameter 
linetype'  is  the  ii^ex  of  linetype  being  defined.  The  pnnuneier  Hsi  Oi  dash  el<%menu'  is  the 
definition  to  be  associated  with  the  index.  The  first  eiement  is  a  dash,  second  a  spaa.  etc.  -  the 
defined  linetype  is  solid  for  II  units,  gap  for  12  units,  solid  for  0  units,  etc.  N  mtm  be  positive. 
■Id  each  dash  eiement  (I)  non-negative.  N*!  means  a  solid  line;  laO  interpreted  at  a  dot 

The  units  of  the  'dash  repeat  length’  are  specified  by  the  'dash  unit  seiector*  pmameter.  The  value 
(^'abstract'  indicates  that  the  implemenuiion  may  ntmnalize  and  map  the  sum  of  the  dash  pauem 
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ekments  u  iu  discieuon.  The  dash  repeal  length'  defines  ihe  length  of  compkie  cycle  of  ihe 
dub  puknu  laeasattd  in  d»  uaiu  of  'dash  uait  sckcxor . 

An  ‘adaptive’  lineiype  is  one  where  every  vtnea  falls  «>  an  inked  pwrurai  of  the  line.  This  is 
accomplished  in  piouers  by  temporarily  snocUfying  ihe  duly  cycle  for  “jch  line  segment  (ceiimg 
funuuon}  sich  that  there  is  always  an  integTal  munber  of  repeau  (and  ali  predefined  linecypes  have 
iheir  gBps.anray  defined  such  ihat  they  begin  and  end  with  inked  or  'pen  down*  portions). 

Refereaccs: 


5.7.x  HATCH  STYLE  DEnMTlON 
Parantters: 
hatch  index  (DO 

oyle  indicainr  (one  of:  pvalleJ.  crosshatch)  (E) 

Kxrh  qiara  ooits  selector  (one  of:  VDC.  mm.  device  uniis,  absoact)  (E) 

angle  (IR) 

duty  c^e  length  (K) 

list  of  hatch  elements  (nf) 

Description: 

This  element  defines  a  hatch  syie  and  assocutes  it  with  an  index  for  fuuut  refertnce. 

The  hatch  index'  parameter  defines  the  index  q(  hatch  style  being  defined.  The  list  of  hatch 
elements'  is  an  array  that  defiMs  ahemating  line  width  and  gap  width  -  i.e..  the  width  of  a  hatch 
line  followed  by  the  width  of  the  space  to  the  next  hatch  line.  The  center  of  the  fm  hatch  line  is 
matrh^  up  with  PATTERN  REFERENCE  POINT,  if  implemented.  0  interpreted  as  thinnest  line 
width  available. 

The  hatch  space  units  selector'  specifics  the  units  of  duty  cycle  length'.  It  also  controls  the 
manner  of  transformation  of  the  hatching:  If  VDC.  then  the  hatching  transforms  with  segment 
transform  and  anisotropic  transforms  (as  if  hatching  iud  done  POLYLINES);  otherwise,  the 
hatching  is  like  ’wallpaper’  that  shows  through  the  polygon*shapcd  hole  -  everything  is  defined  m 
device  units  and  hatching  performed  in  device  space.  The  value  of  'abstract'  mdicates  that  the 
impiemeniaiion  may  noi^ire  and  map  the  sum  of  the  list  of  hatch  elemeau  at  iu  discreuon. 
The  duty  cycle  length'  is  measured  perpendicular  to  the  hatch  line.  The  sum  of  hatch  elnnenu  in 
the  hatch  elonent  list  is  normalized  to  this  distance  before  presentation  of  the  hatch  on  the  view 
surface. 

The  'angle'  parameter  is  measured  in  the  uniu  specified  by  the  'hatch  space  uniu  selector .  It 
consisu  of  two  components,  dx  and  dy.  defining  a  vector. 

References: 


5.7.x  UNE  CAP 
Parameters: 

line  cap  indicauv  (one  of:  buo,  round,  projecting  square)  (E) 

Description: 

The  line  cap  style  is  defined  for  subsequent  line  eJemems.  The  line  cap  style  determines  the 
appearaiKe  of  open  endpoinu  (as  apposed  to  interim’  vertices)  of  line  elemenu.  The  defined  styles 
■e; 
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bus  cap: 

the  line  is  squared  off  at  the  etuipoint.  duat  is  no  projccuon 
br  tmd  the  endpoint 

round  cap: 

a  semicircular  arc  wiih  diameter  equal  to  the  line  width  is 
drawn  around  the  endpoint  and  filled  in.  The  drawn  line  thus 
projecu  beyond  the  endpomt 

projecting  square  cap: 

the  tine  is  squared  off  at  a  distance  equal  to  half  the  line  width 
beyond  the  endpoint 

References: 

5.7Jt  USE  JOIN 

Parameters: 

line  join  indicator  (one  of:  miter,  round,  bevel)  (£) 

Description: 

The  line  join  style  is  defined  for  subsequent  line  elements.  The  line  join  style  defines  the 
appearance  of  interior  vertices  of  polyline  elemenu  and  of  compound  line  elements.  The  defined 
styles  arc: 

miter  join; 

the  outer  edges  of  the  two  adjoining  line  segments  are 
eaiended  until  they  meet  at  a  point 

round  join: 

a  circular  arc  with  diameter  equal  to  the  line  width  is  drawn 
around  the  vertex  between  the  adjoining  segments  and  is  filled 
in.  producing  a  rounded  comer. 

bevel  join: 

the  adjoining  line  segments  are  terminated  with  a  buit  cap. 
and  the  resulting  triangular  notch  is  filled  in. 

References: 


5.7J£  EDGE  CAP 
Parameters: 

edge  cap  tndicauar  (one  of:  buu,  round,  projecting  square)  (E) 

Description: 

The  edge  cap  style  is  defined  for  subsequent  edge  elements.  The  edge  cap  style  determines  the 

appearance  of  open  endpoints  of  filled  area  edges  (such  as  may  result  frexn  a  mixture  of  visible  and 

invisible  edge  segments).  The  defined  styles  are: 

bus  cap:  the  edge  is  squared  off  at  the  vertex,  there  is  no  projection 

beyond  the  eadpoira. 

round  cap:  a  aemidteuiar  ate  with  diameter  equal  to  the  edge  width  is 

dnwn  around  the  endpoint  Slid  filled  in.  The  drawn  edge  thus 
projects  beyond  the  eadpoinL 

projecting  square  cap:  the  edge  is  squared  off  at  a  distance  equal  to  half  the  edge 

width  beyond  the  endpoint. 
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5.7.x  FONT  SCORE  TYPE 


Parameters: 

Kore  type  (one  of:  sinkeoui.  underline,  overscore.  a  none) 

Descriptioa: 

The  score  type  is  set  (he  the  value  specified  by  the  parameter. 

The  following  score  type  are  assigned: 

1:  siikBOui 
1  uodencore 
3:  oeeracore 
4:  aone 

The  seme  type  stiikeoui'  is  a  line  drawn  through  each  character  in  the  stnng  at  the  hair  vcrjcaJ 
alignment  posidoo. 

The  score  type  'underscore'  is  a  line  drawn  below  each  character  in  the  stnng  at  the  ’boiiom  vcoica! 
alignment  position. 

The  score  type  'overscore'  is  a  line  drawn  above  each  character  m  the  stnng  at  the  top  verucal 
alignment  posttion. 

The  score  type  'none'  remove  all  scoring. 

Rcfcreaces: 
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ANSI  X3H3 

Infomution  Pracesang  Sysims  - 

Gjmpuitr  Graphics  - 

McafiJe  for  the  Sutfage  and  Transfer 
of  Piciurt  Description  Infonnauon 


Pan  1 

Functional  Spccifjcauon 
(Caused) 

Addendijn)3 

Drift  Docoinent  2.0 
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Pxge  100 

Clause  d:  Add  the  following  default  specifications; 


CONIC  ARC  TRANSFORMATION  MATRIX: 
PEL  ARRAY  CUP  RECTANGLE; 

PEL  ARRAY  REFERENCE  POINT; 

Clipping  Region; 

(BEGIN/END  CUP  REGION) 

Shielding  Region: 

(BEGIN/END  SHIELD  REGION) 

CUP  INDICATOR: 

SHJxUD  INDICATOR; 

COLOUR  ;--£?RESENTATION  METHOD: 


identity  matrix 

(.0X1)  upper  left.  (N-IX-I)  lower  right,  where 
N  is  the  number  of  pels  per  line,  and  L  ts 
the  number  of  lines  in  tl»  last 
COMPRESSED  PEL  ARRAY  clcmenL 

upper  left-hand  comer  pouu  of  the  def^t 
VDC  extent 

VDC  Extent 

VDC  Extent 

On 

Off 

RGB 
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Attachment  7 ; 

US  Comments  on  Addendum  3  working  Draft 
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uo  \^umxneuc3 

CGM  Addendum  3  Working  Draft 


1.  Introduction 

This  document  contains  the  US  comments  on  the  Working  Draft  of  Addendum  3, 
document  version  dated  89/07/18.  The  commen  j  are  divided  into  three  sections: 
the  overall  comments  of  the  next  section;  a  checklist  comparing  Add.3  Working 
Draft  content  to  the  NWI  and  requirements  documents;  and  a  section  of  detailed 
technical  comments.  In  addition  the  US  intends  to  bring  contributions  of  revised 
text  to  the  Olinda  Metafile  RG  Meeting. 

2.  Overall  Comments 

2.1  Schedule 

The  schedule  must  be  considered  a  requirement  at  least  as  strong  as  any  of  the 
other  requirements.  This  may  force  compromises  on  technical  content.  In  particu¬ 
lar  attempts  to  develop  technical  areas  which  will  likely  be  lengthy,  or  will  require 
liaison  with  other  standards  work  which  has  a  significantly  longer  timetable,  should 
be  postponed.  The  US  believes  that  the  work  can  and  should  be  completed  on  the 
timetable  projected  in  the  NWI. 

2.2  Completeness  of  the  draft 

The  US  believes  that  the  current  Working  Draft  is  not  sufficiently  complete  for  DP 
registration.  The  functionality  is  incomplete  with  respect  to  that  detailed  in  the 
NWI  and  Requirements  documents,  as  pointed  out  below  in  "NWI/Requirements 
Checklist.”  The  defaults  are  missing  for  many  elements  that  need  them.  With  the 
correction  of  these  omissions,  and  the  addition  of  the  encodings,  the  Working  Draft 
will  be  complete  enough  for  DP  registration  and  ballot. 

2.3  Compatibility  with  other  SC24  Work 

.As  stated  in  the  NWI  the  .Addendum  3  work  should  coordinate  with  the  3024  work 
in  APIs  and  Reference  Models.  However  the  Add.3  metafile  has  strong  ties  to  com¬ 
mon  practice  which  is  outside  of  the  scope  of  SC24  standards  as  well  —  proprietary’ 
CAD  databases,  desktop  publishing  ^rstems,  page  description  languages,  and 
graphic  arts  workstations  to  name  a  few.  The  US  believes  that  there  should  not  be 
arbitrary  differences  between  this  work  and  work  on  existing  or  new  .APIs.  How¬ 
ever  the  US  defines  the  following  priorities  for  possibly  resolving  conflicting  require¬ 
ments:  schedule  and  identified  functional  requirements  must  have  the  highest  prior¬ 
ity. 

2.4  Document  form 

Addendtim  3  should  ultimately  be  processed  as  a  complete  document,  i.e.,  CGM 
plus  Addendum  1  plus  Addendum  3  should  be  merged  into  a  single  document  for 
review  and  advancement.  Because  this  is  going  to  be  fairly  unwieldy,  we  think  that 
this  should  be  done  at  the  stage  that  DP  text  is  prepared  and  the  DP  ballot  ini¬ 
tiated.  At  the  Working  Draft  stage  it  is  easier  to  focus  on  functional  completeness 
and  correctness  (and  ignore  document  completeness  and  consistency)  in  the  current 


117 


format.  If  tivo  DPs  are  anticipated,  then  the  consolidation  should  happen  at  the 
second  DP  stage. 

2.5  Relationship  to  Addendum  I 

Addendum  3  should  be  a  proper  superset  of  Addendum  1.  A  legal  .A.dd.1  metafile 
should  be  a  legal  Add.3  metafile. 

2.6  Further  Coordination  with  Improved  Text  Model  Study  Group 

The  US  recommends  that  any  further  work  on  Improved  Text  Model  shomd  take 
place  in  the  Reference  Models  RG  of  WGl.  In  the  meantime  the  work  done  so  far. 
and  useful  extensions  from  current  practice  in  the  industry,  should  guide  the 
improved  text  facilities  of  Add-3. 

2.7  Further  Coordination  with  PDG  Study  Group 

No  specific  requirements  for  Add.3  have  derived  from  the  work  of  the  PDG  study 
group.  The  US  believes  that  such  requirements  are  most  likely  to  be  applicable  to 
Addendum  2,  the  3D  metafile,  when  and  if  the  scope  of  such  is  defined.  If  any 
specific  requirements  for  2D  metafile  support  can  be  stated,  then  those  should  be 
observed  in  the  work  on  Add.3. 
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3.  NWI/Requirementa  Checklist 

The  following  list  is  extracted  from  the  NWI  and  the  requirements  document  for 
Addendum  3.  Each  item  is  examined  and  the  state  of  the  Working  Draft  is 
categorized  for  that  'tern.  Ail  MISSING  and  INCOMPLETE  conditions  must  be 
corrected  before  DP  registration.  The  text  and  font  facilities  need  significant  work, 
and  we  have  dealt  with  them  in  a  separate  section  later  in  this  document. 

3.1  Advanced  2D  drawing  capability 

a.  curves 

—  Bezier  curves:  MISSING. 

—  Rational  B-splines:  OK. 

—  Parametric  spline  curves:  OK. 

—  Conics,  and  conic  arcs:  OK. 

b.  additional  line  attributes 

—  line  cap:  OK. 

—  line  join:  OK. 

—  mitre  limit  control:  OK. 

c.  composite  line  primitives:  OK. 

d.  user  defined 

—  line  types:  OK. 

—  hatch  styles:  OK. 

—  marker  types:  MISSING. 

e.  arbitrary  text  path:  OK. 

f.  filling  mechanisms 

—  additional  standardized  hatch  styles:  MISSING. 

—  interpolated  fill:  MISSING. 

—  geometrically  specified  patterns:  MISSING. 

g.  general  transformations:  3x3  (and  2x3)  transformation  matrices  to  allow  for 
affine  and  projective  transformations:  MISSING  (except  for  conics). 

3.2  Improved  text  and  font  support 
Much  work  needed. 

3.3  Arbitrary  boundaries  for  clipping  and  shielding 

OK. 


3.4  Additional  color  models  beyond  RGB 

a.  CIE:  OK  (but  check  against  latest  draft  of  ISO  8613  Color  Addendum). 

b.  CM^lv:  OK  (but  check  against  latest  draft  of  ISO  8613  Color  .Addendum;. 

c.  spot  colour:  OK  (but  check  against  latest  draft  of  ISO  8613  Color  .Addendum). 
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3.5  Additionai  image  storage  and  transfer  capabilities 

CodlDg/compresHon  tecimiques:  INCOMPLETE,  (cleanup  paraineterizatiorn.  ad 
local  color  precision,  iii.^rove  descriptions,  address  the  issue  of  ccmpressich  an 
color). 

3.8  Symbols 

a.  external  reference  to  libraries  of  named  s>'tabois:  MISSING. 

b.  user-defined  internal  libraries;  OK  (adequately  covered  by  Addendum  1 
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4.  Specific  Technical  Commenta. 

4.1  Bundles 

It  is  aot  described  anywhere  how  the  new  attributes  (line  attributes,  lext/font  attri¬ 
butes,  etc)  relate  to  the  bundle  concept  of  CGM  and  other  SC24  standaf^^  They 
should  not  be  bundled.  Predefined  bundles  are  used  for  distinguishabiiity  where 
exact  appearance  does  not  count,  and  this  is  contrary  to  the  whole  reason  for  these 
"precise  control"  attributes.  Settable  bundles  in  static  CGM  only  provide  a  macro 
mechanism,  and  the  utility  of  such  a  mechanism  docs  not  justify  the  complexity  of 
adding  these  to  bundle  definitions. 

4.2  CUpping  to  Arbitrary  Boundaries 

The  .\dd.3  requirements  identify  the  need  for  clipping  to  arbitrarj'  boundaries,  and 
also  the  need  for  arbitrarily  specified  geometric  fill  (the  latter  has  not  been  defined 
yet).  The  latter  can  provide  the  same  capability  as  the  former.  Clause  4  should 
have  text  comparing  and  contrasting  the  features,  and  should  furthermore  address 
(and  proscribe)  possible  recxirsive  situations  that  could  arise  with  the  filling  feature. 

4.3  Compound  Clip  Indicator 

There  should  be  a  COMPOUND  CLIP  INDICATOR  which  controls  the  clipping  lo 
arbitrar>'  boundaries. 

4.4  Line  Types  and  User-defined  Line  type 

a.  .\re  the  interior  endpoints  of  a  dashed  line  capped?  Options  are;  yes,  no,  or 
selectable  by  a  new  option  setting  element. 

b.  The  need  for  ’millimeters'  and  ’native  device  units’  as  modes  for  dash  unit 
selector  of  user  line  type  needs  to  be  justified 

c.  There  shou.i  be  a  'line  width  relative’  mode  for  dash  unit  selector  for  line  type 
definition. 

d.  There  should  be  a  LINE  STYLE  CONTINUA-  TION  f\mction,  which  applies 
to  both  user  defined  and  predefined  dashed  lines.  The  ’adaptive’  parameter 
should  be  removed  from  user  defined  linetype.  LINE  STYLE  CONTINUA¬ 
TION  should  minimally  have  the  values  "continue”,  "restart",  or  "adaptive  con¬ 
tinue".  This  parameter  might  be  subject  to  registration  of  values  as  well,  as 
some  of  the  target  application  areas  of  Add3  have  very  specific  requirements 
for  how  a  dashed  line  ’is  drawn  with  respect  to  dash  lengths  and  inking  of  ver¬ 
tices. 

e.  There  should  be  an  INITIAL  DASH  OFFSET  element,  which  specifies  how  far 
into  the  line  pattern  to  start  drawing  a  new  polyline. 

f.  The  text  of  User  Linetype  needs  much  clarification  and  improvement  including 
definition  of  missing  terms  such  as  "N",  "gap-array"  and  "duty  cycie". 

g.  Which  of  the  new  Line  Type  functions  affect  edges.  Is  it  intended  to  have 
equivalent  functions  for  edges? 
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4.5  Shielding 

Multiple  disjoint  shield  regions  are  needed.  This  could  be  achieved  in  a  number  of 
ways. 

— The  defin’t.ion  of  a  angle  region  could  allow  for  'islands,  muc’-  as  POLYGON 
SET  does  for  filled  areas. 

— or  there  could  be  multiple  definitions  of  regions,  each  associated  with  an  Index 
and  tied  to  its  shield  indicator  by  the  index. 

4.6  Additional  line  caps 

A  Line  Cap  style  of  ’triangular’  is  needed. 

4.7  Conies  and  conic  arcs 

a.  Section  5.8JC  states  "the  conic  arc  entity  must  be  positioned  such  that  each  o  f 
its  axes  is  parallel  to  either  the  Xv  axis  or  Yv  axis”.  Clause  4  does  not  have  a 
similar  restriction.  If  the  latter  is  correct,  is  there  need  for  the  conic  arc 
transformation  matrix? 

b.  The  assertion  has  been  made,  but  not  yet  demonstrated,  that  the  conics  can  ail 
be  represented  by  relatively  simple  splines.  If  tins  can  be  demonstrated  then 
the  conic  arc  entity  should  be  removed  in  favor  of  a  non-normative  note 
describing  how  parabolas  and  hyperbolas  can  be  realized  with  splines. 

4.8  General  tranafarmationa 

The  need  for  this  was  stated  in  the  NWI  and  requirements.  It  'is  not  addressed  in 
the  Working  Draft,  and  it  b  not  clear  exactly  what  was  intended  by  the  require¬ 
ments  statement.  Thb  needs  to  be  studied  and  clarified.  In  particular,  do  Segment 
and  Copy  transforms  provide  whatever  capability  b  needed? 

4.9  Splines 

a.  Unified  Formulation.  If  formulations  can  be  demonstrated  which  are  con- 
sbtent  with  the  work  of  STEP,  PHIGS-f,  and  other  related  areas,  and  if  these 
can  be  shown  to  easily  subsume  and  support  the  formulations  in  the  Working 
Draft,  then  these  formulations  should  be  used.  Such  claims  have  been  made 
but  not  demonstrated. 

b.  Description.  Tutorial  information  on  the  various  splines  and  curves  should  be 
included  In  an  annex. 

c.  The  "curve-type”  and  "H"  parameters  of  the  Parametric  Spline  curve  are 
meaningless  for  the  definition  of  the  curve  and  should  be  removed. 

d.  The  "equation  type"  flag  should  be  removed  —  to  get  a  polynomi?!  one  may 
put  in  an  array  of  weights  that  sum  to  zero.  A  void  array  should  be  degen¬ 
erate  or  illegal. 

e.  Closed  curves.  Clause  4  indicates  a  RATIONAL  B-SPLINE  CUR'VE 
CLOSED  element,  which  b  a  Filled  Area  element.  Thb  b  missing  from 
Clause  5. 
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4.10  PEL  ARRAY 

a.  The  compression  parameters  should  be  separated  out  as  a  distinct  {control  or 
attribute)  element. 

b.  Line  spacing  and  pel  spacing  should  be  real  values  specified  as  PELS/VDC. 

c.  liie  IMAGE  APERATURE  serves  no  useful  purpose  that  cannot  be  met  with 
CLIP  RECTANGLE  —  it  should  be  removed. 

d.  There  should  be  a  'local  colour  precision’  parameter  for  PEL  .ARfLAlt'.  It 
should  also  be  explicit  that  not  ail  combinations  of  compression  and  l.c.p  are 
legal  (e.g.,  l.c.p  must  be  1  for  CCITT). 

e.  The  document  needs  more  work  on  colour  compression  techniques. 

f.  There  is  no  definition  of  what  a  PEL  is,  and  how  it  differs  from  a  ceil  or  a 
pixel. 

4.11  TILED  PEL  ARRAY 

It  is  not  clear  that  this  is  not  in  fact  a  graphical  primitive  but  a  "tiling  control  func¬ 
tion".  Better  explanation  and  a  name  like  PEL  .ARR.\Y  TILLN’G  CO.NTROLS 
would  help. 

4.12  Color  Models 

The  terminology  "Color  Model"  is  commonly  used  and  should  replace  the  terminol¬ 
ogy  "Colour  Representation  Method"  of  the  Working  Draft. 

The  color  models  HLS  and  HSV  are  missing.  There  seems  to  be  no  good  reason  to 
exclude  them,  particularly  since  the  are  in  use  in  the  API  standards  now. 

4.13  User  Defined  Marker  Types 

These  are  stated  in  the  requirements,  and  are  missing  from  the  Working  Draft.  It 
should  be  evaluated  If  the  need  for  this  is  can  be  satisfied  by  applying  the  segment 
mechanisms  of  Add.l 

4.14  Additional  Hatch  Styles 

These  are  stated  in  the  requirements,  but  there  are  none  in  the  Working  Draft. 
The  requirements  have  not  been  specific  on  what  styles  were  anticipated.  The  US 
simply  notes  this  omission  and  has  no  styles  to  suggest  at  this  time. 

4.15  Interpolated  Fill 

This  is  stated  in  the  requirements,  but  is  missing  from  the  working  draft.  There 
are  very  many  ways  to  do  smooth  shaded  fill.  The  activity  in  PHIGS  and  current 
practice  in  the  industry  should  be  examined  for  guidelines  for  a  base  proposal  or  ini¬ 
tial  set  of  methods. 

4.18  Transformation  of  Hatches 

There  should  be  a  HATCH  TRANSFORM  DESIGNATOR  element.  For  engineer¬ 
ing  practices  hatches  do  not  transform,  but  for  other  applications  they  do.  There 
should  be  a  control  or  attribute  element  to  control  this  behavior. 
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4.17  References  to  External  Symbob 

This  capibility  is  stated  in  the  requirements,  and  is  missing  from  the  Working 
Draft.  This  capability  b  useful  in  engineering  practice  and  for  "clip  art"  in  graphics 
arts.  The  issue  of  referencing  external  resources  which  are  not  part  of  or  defined  by 
this  or  another  standard  is  the  key  issue  which  needs  to  be  solved  in  order  to 
include  this  capability.  Once  that  issue  'is  resolv  d  it  appears  promising  that  the 
existing  segmentation  facility  of  Add.l  can  be  used  to  provide  a  complete  mechan¬ 
ism. 

4.18  Improved  Text  and  Font  Capability 

Aside  from  the  many  specific  issues  identified  below,  the  US  questions  the  level  of 
font  resource  'information  which  ‘is  being  carried  in  the  metafile.  The  information 
can  be  grouped  into  levels  of  detail  and  preciseness.  These  are  based  on  the  font 
resource  subsets  of  ISO  9541: 

—  Font  Description:  resource  name  itself,  family  name,  design  class,  weight,  pos¬ 
ture,  etc. 

—  Font  metric  Information 

—  Glyph  metric  and  kerning  information 

—  Glyph  shape  definition. 

There  should  be  some  amount  of  the  tughest  level  information  in  the  metafile,  as 
part  of  the  font  callout  procedure.  There  should  be  ix^ne  of  the  lowest  level.  How 
much  of  the  Intermediate  levels  of  information  should  be  included  is  an  open  issue. 

We  note  that  the  latest  draft  of  ISO  9541  has  dropped  the  font  information  subsets 
concept,  which  we  considered  useful  information  to  application  comrauraities  such 
as  computer  graphics  metafiles. 

Following  are  specific  technical  topics  relating  to  text. 

a.  Available  glyphs  for  TEXT  primitives.  The  repertoire  of  glyphs  available  with 
the  current  CGM  character  set  mechanisms,  and  means  to  access  glyph  collec¬ 
tions,  is  not  adequate.  A  companion  standard  of  ISO  9541  —  ISO  10036  — 
establishes  the  Association  for  Font  Information  Interchange  (afil)  as  the  regis¬ 
trar  for  glyphs  and  glyph  collections.  Afii  estimates  that  25000  ^yphs  will  be 
re^stered  in  the  next  2  years.  It  appears  that  each  will  have  a  unique  4-byte 
identifier.  AdcL3  must  have  a  way  to  access  glyph  collections  that  do  not  fit 
into  the  traditional  model  of  "G-sets"  and  character  set  switching  defined  by 
ISO  2022.  At  the  least  a  new  value  of  CHARACTER  CODING 
ANNOUNCER  is  needed.  Then  the  metafile  might  use  afii  4-byte  identifiers 
and/or  mapping  tables  to  convert  4  byte  ID’s  to  1  or  2  byte  codes. 

b.  Inclusion  and  formulation  of  glyph  defirdtions.  There  are  many  technical  prob¬ 
lems  with  the  formulation  of  glyph  definitions.  It  'is  the  US  position,  however, 
that  glyph  defimtions  do  not  belong  in  the  metafile.  There  are  two  reasons: 

—  Glyph  shape  descriptions  do  not  belong  in  the  metafile;  they  should  be  part 
of  the  external  font  resource,  which  may  accompany  the  metafile  but  is  not 
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a  part  of  it. 

—  The  work  b  premature  with  respect  to  work  on  ISO  9541/3,  which  is  just 
commencing. 

Note:  the  US  believes  that  COM  (Add.3)  technology  should  be  used  to  define 
an  encoding  of  glyph  shape  definition,  as  part  of  an  external  font  resource,  fol¬ 
lowing  the  functional  guidelines  established  in  ISO  9541/3,  when  work  on  that 
part  is  suflBciently  advanced. 

c.  BOXED  TEXT  should  be  dropped  and  a  RESTRICTED  TEXT  METHOD 
element  added  such  that  the  RESTRICTED  TEXT  element  can  function  in 
the  manner  described  for  BOXED  TEXT.  The  new  mode  element  should 
standardize  at  least  some  text  fitting  options  such  as:  as- now,  text  simply  is 
adjusted  not  to  violate  box;  exaclrfit,  the  CHARACTER  HEIGHT  is  super- 
ceded  by  the  box  height  and  the  string  width  a  adjusted  to  exactly  fit  the  box 
width;  width-fit,  as  previous,  but  CHARACTER  HEIGHT  is  not  altered 
regardless  of  its  relationship  to  the  box;  isotropic-scale,  in  which  the  text  is 
scaled  without  distortion  until  both  dimensions  fit  and  at  least  one  dimension 
fits  exactly;  etc.  These  are  just  some  possibilities.  This  should  be  a  parameter 
subject  to  registration.  There  may  be  other  desirable  values  which  give  more 
detail  about  layout  algorithms. 

d.  Access  to  ISO  9541  font  resources.  Methods  to  access  all  information  in  9541 
format  font  resources  external  to  the  metafile  are  needed.  Precisely  what  the 
practical  implications  are  remains  an  open  issue.  The  shape  description  infor¬ 
mation  must  be  easily  accessible.  At  least  one  of  the  technologies  used  to 
describe  the  shapes  in  the  font  resource  should  be  compatible  with  the  CGM. 

e.  Font  scoring.  The  current  wording  should  be  clarified  to  indicate  that  the 
score  character  and  the  exact  score  position  defined  in  the  font  resource  for 
the  current  font, 

f.  Font  Terminology.  Add.3  terminology  should  be  aligned  better  with  9541. 
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Attachment  8: 

Draft  Addendum  Text  for  CGM  Addendum  I 
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CGM  Addendum  1 


Part  1 
Draft  Copy 
August  1989 
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Sub-cUuse  O.l:  Add  (he  following  u  the  end  of  the  tub-cUute: 

This  picture  description  includes  the  cspsbiLlty  for  dochbing  suuc  pictures.  Suuc  ptcnires  are  those  where  eiemenu 
which  may  lead  to  dynamic  effects  (for  example  those  leading  to  regtneraoonl  are  prtthibnod  within  the  picture  body 

Page! 

Sub-cJauM  OJ:  Add  the  following  at  the  end  of  item  c): 

It  should  also  not  preclude  further  extensions  to  support  funcc  standaids. 

Page! 

Sub-clause  0  3:  Add  the  following  at  the  end  of  item  d); 

It  should  include  the  capability  to  support  ISO  7942  (CKS)  suuc  picture  capture. 

Page  3 

Sub-clause  0.8;  Add  the  following  at  the  end  of  the  Htst  paragraph; 

The  CGM  spesnfies  the  elements  required  to  support  ISO  7942  (CKS)  static  picnxre<apniie. 

Page  3 

Sub<lausc  0.8;  Add  the  following  at  the  end  of  the  clause: 

There  is  a  very  close  relationship  between  many  of  the  eiementt  in  ISO  8632-I987/AJDD.1  and  a  subset  of  the  funcuons 
in  the  CCI  (Computer  Graphics  Interface  •  ISO  OP  9636). 

Page* 

Cause  1 :  Add  the  following  at  the  end  of  the  lint  paragraph; 

This  picmre  description  includes  the  capability  for  describing  static  images. 

Pages 

Cause  2:  Add  (he  following  to  the  list  of  references: 

ISO  DP  9636  Information  processing  systems  -  Computer  Graphics  -  Interfacing  techniques  for  dialogues  with  graf^tcal 
devices  (CCI).  Para  1  -6. 

Page  6 

Sub-clause  3. 1.2.6:  Oefiniiion  of  graphical  eiemenu 
Insert  primitive''  between  'graphical''  and  "element '. 

Page  d 

Cjusc  3:  Add  the  I'ollowuig  to  (he  list  of  derinitions  and  abbreviaiions; 

anisotropic  mapping;  A  mapping  in  which  the  scale  factors  applied  along  each  axis  are  noi  equaL  This  is  often 
used  in  reference  to  the  mapping  from  VDC  lo  distance  units  on  the  ^ytical  drawing  surface.  Sec  'Isotropic  mapping  ’ 
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boundary:  The  muhenmical  \octu  th«  defines,  is  sbnraa  VDC  i|Mce,  the  Umiu  of  i  region  u>  be  fined  (for  fill 
primitives  and  closed  figures).  The  visual  appearance  of  imchoe  style  "hoilov*’  ctmsisu  of  a  depieuon  of  the  boundary 
obtained  after  clipping  has  been  taken  into  locoimL  The  bousdary  is  distmci  from  the  edge  as  a  includes  ihe  mtersecuon 
of  the  region  with  the  perimiur  of  the  effective  clipping  region- 

character  set:  The  set  of  displayajlc  symbols  mapped  to  individual  characters  in  a  TEXT.  APPEND  TE-»  T.  or 
RESTRICTED  TEXT  string.  This  cotiesponds  to  the  *G-set*  definetfin  ISO  2022.  A  character  set  is  independc.i  of  she 
font  or  typefxe:  esamples  of  diaraeter  scir  ASCII  (X3.4XCennan.  Katakna. 

cUpping  mode:  A  generic  term  referring  to  one  of  Line  Gipping.  Marker  Gipping  or  Edge  Gipping  Modes  An 
object  clif^ng  may  be  either  locua',  shepe'  or  1ocna  then  shape'. 

closed  figure:  A  compound  primitive  that  behaves  as  a  fill  primiiive  of  more  general  shape.  It  is  formed  by 
bracketing  a  sequence  of  line  or  fill  primitives,  edge  atoibuiea.  and  certain  controls,  with  theelemenu  BEGIN  FTCL'RE 
and  END  RGURE 

compound  primitive:  A  compound  primitive  is  specified  by  a  sequence  of  COM  elements,  as  opposed  to  ^mmiuvcs 
represemed  by  a  single  element.  Compound  teat  and  closed  figures  are  taanr^ea  of  compound  pnmtuvcs  ui  the  CCM 

compound  text;  A  compound  primitive:  formed  through  the  use  of  APPEND  TEXT.  There  may  be  lunbuic  changes 
between  poruons  of  the  resulting  complete  teat  suing. 

device  coordinates:  The  esoidinaiea  native  to  a  device:  drvice-depcsidcni  coordinater  physical  device  coordtnaies 

device  viewport:  A  rectangular  subset  of  the  physical  dnwing  surface  inu>  which  VDC  EXTE.NT  is  mapped  See 
■eflecuve  viewport'. 

edge:  The  rendering  of  the  perimiter  of  a  filled  region,  controlled  by  edge  attributes.  Edges  are  clipped  after  being 
applied  to  the  boundary,  as  dlsunci  from  the  rendition  of  the  boundary  obtained  from  imenor  style  'hollow  See 
“bomiary'. 

cfTcetIve  vlawport:  The  actual  viewport  resulting  from  forced  isotropic  mapping  from  the  VDC  extent  to  the 
viewport. 

foreground  coiourt  The  colour  used  in  the  rendering  process  in  which  prinuDvea  are  rendered  on  the  drawing  surface, 
u  opposed  to  the  BACKGROUND  COLOUR  or  AUXILIARY  COLOUR.  The  foreground  colour  is  set  separately  for 
each  class  of  primiuvcs. 

global  segment:  A  segment  that  is  defined  in  the  Metafile  Description  (see  segment).  It  may  be  referenced  from 
within  any  picture 

graphic  object:  ••••••••cCI************””********************""******* 

isotropic  mapping:  A  mapping  which  is  invariant  with  respect  to  direction:  equal  scaling  in  all  orthogonal 
representational  dimensions.  Often  used  to  describe  the  mapping  from  VDC  lo  distance  units  on  the  physical  drawing 
surface  (see  'anisotropic  mapping'). 

local  segment:  A  segment  that  is  local  to  the  picinra  ia  which  it  appears. 

region:  In  the  context  of  closed  figures  or  the  POLYGON  SET  dement,  an  area  that  is  explicidy  or  implicitly  closed, 
that  IS  a  subset  of  the  full  area  being  filled.  Regiona  ca  be  nested,  disjoint  or  overiappmg.  The  boundaries  of  ail 
regions  «e  considered  together  when  applying  the  imerior  ten  for  filling  a  doaed  figurt  or  K>LYGON  SET. 

segment:  A  collection  of  primitives,  primitive  aaribotes  and  some  additional  attributes  aasociaied  with  the  segment  as 
a  whole.  See  'segment  aiiribuies'. 

scemrnt  attribute:  An  attribute  aasociaied  with  a  segmem  u  a  whole  as  opposed  to  attributes  of  iitdividuai 
pnmtuvcs. 

■lire  vpei'incjiiun  mode:  A  generic  term  for  Line  Width  Specification  Mode.  Edge  Width  Spccificatian  Mode,  or 
.^ta(kcf  :ii,cc  Spectficauan  Mode.  A  size  specificatton  mode  may  be  VDC  or  scaled,  the  latter  being  referenced  to  a 
nunim.d  >i/c  m  device  coordinate  space. 
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skewed:  Used  to  describe  stroke  precision  test  when  the  CHARACTER  ORIENTATION  vectors  «e  non- 
perpendicnlsr,  CELL  ARRAYs  when  the  three  defining  poinu  form  •  ptriileiogntn  which  is  not  i  recisngie.  or  s 
segment  tnnsformstion  that  causes  rectangles  to  become  non-iecungutar  peniielograins. 
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Sub-clause  4.1:  Add  (he  following  ax  the  end  of  the  list  of  classes  of  elements: 
Segment  Elements,  which  enable  the  grouping  and  manipulation  of  elements. 


Page  9 


Sub-clause  4.1;  Add  the  following  after  the  third  paragraph: 

Graphical  output  primitives  and  attributes  may  be  grouped  in  segments.  Segment  attribute  elements  control  the 
appeanm  of  segmerus. 
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Sub-clause  4.2:  Add  the  following  at  the  end  of  the  sub<iause: 

Groups  of  elements,  called  segments,  are  delimited  by  BEGIN  SEGMENT  and  END  SEGMENT.  Each  segment  is 
uniquely  identified  by  a  segment  idemifter.  Segments  may  be  defined  in  the  Metafile  Descriptor  or  within  picture  bodies. 

Page  JO 

Sulxlause  4  J:  Add  the  followutg  to  the  list  after  the  Cast  paragraph: 

NAME  PRECISION 
MAXIMUM  VDC  EXTENT 
SEGMENT  PRIORITY  EXTENT 

NOTE:  Other  elements,  as  defined  in  this  standard,  may  appear  within  the  Metafile  Descriptor  within  the  definition  of 
a  global  segmenL 

Page  JO 

Sub-clause  4  J:  Add  the  following  at  the  end  of  the  sub-clause: 

NOTE;  It  is  recommended  that  the  following  elements:  METAFILE  VERSION.  METAFILE  ELEMENT  LIST  and 
METAFILE  DESCRIPTION  appear  first  in  the  Metafile  Descriptor  and  in  the  order  listed. 
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Sub-clause  4  J.2 :  Add  the  following  ai  the  end  of  the  sub-clause: 
Ftffther  shorthands  ire  defined  for  groups  of  CGM  elements. 


Page  J I 

Sub-clause  4  J.2:  Add  the  following  clauses  at  the  end  of  the  sub<lause: 

4.3.2J  Ver.2-stalic-all  set 

The  Ver.2-iuttic-all  set  may  be  used  to  indicate  all  the  elements  in  (he  drawing-plus-control  set  and  ail  the  additional 
elemems  defined  in  ISO  8632/1  -  1987/.A(ld.l. 

4J.2.4  Extcnded-prlmjtivfs  set 
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The  Extended-primitives  set  may  be  used  to  indicate  those  primitives  which  are  not  deflrted  in  ISO  7942  (GKS).  These 
elements  are: 

DISJOINT  POLYLINE 
RESTRICTED  TEXT 
APPEND  TEXT 
POLYGON  SE. 

RECTANGLE 

CIRCLE 

aRCULAR  ARC  3  POINT 
ORCUIAR  ARC  3  POINT  CLOSE 
QRCULaR  arc  CENTRE 
aROJLAR  ARC  CENTRE  CLOSE 
ORCULaR  arc  CENTRE  REVERSED 
ELLIPSE 

elliptical  ARC 
ELLIPTICAL  ARC  CLOSE 
CONNECTING  EDGE 


4J.2J  Ver.2-5tatlc-gksm  set 


The  Ver.2-static-gksm  set  includes  elements  for  ISO  7942  (GKS)  static  picture  capmre.  The  elements  included  in  the 
VerJI-static-gksm  set  are; 


BEGIN  METAFILE 
BEGIN  PICTURE 
BEGIN  PICTURE  BODY 
END  PICTURE 
BEGIN  SEGMENT 
END  SEGMENT 
END  METAFILE 
METAFILE  VERSION 
METAFILE  DESCRIPTION 
VDCTYPE 
INTEGER  PRECISION 
REALPREGSION 
INDEX  PRECISION 
COLOUR  PREOSION 
COLOUR  INDEX  PREOSION 
NAME  PRECISION 
MAXIMUM  COLOUR  INDEX 
COLOUR  value  extent 
METAFILE  ELEMENT  UST 
METAFILE  DEFAULTS  REPL 
FONT  UST 

CHARACTER  SET  UST 
CHAR  CODING  ANNOUNCER 
MAXIMUM  VOC  EXTENT 
SEGMENT  PRIORITY  EXTENT 
VDC  EXTENT 
DEVICE  viewport 
DEVICE  viewport  MAPPING 
DEVICE  VPORT  SPEC  MODE 
LINE  REPRESENTATION 

marker  representation 

TEXT  representation 

niL  representation 

VDC  INTEGER  PREOSION 
VOC  REAL  PRECISION 

CUP  rectangle 
POLYUNE 
POLYMARKER 
TEXT 
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POLYGON 
CELL  ARRAY 
^DP 

UNE  BUNDLE  INDEX 
LINE  TYPE 
LINE  WIDTH 
UNE COLOUR 
MARKER  BUNDLE  INDEX 
MARKER  TYPE 
MARKER  SIZE 
MARKER  COLOUR 
TEXTBUNDLE  INDEX 
TEXT  PONT  INDEX 
TEXT  PRECISION 
CHAR  EXPANSION  FACTOR 
CHARACTER  SPACING 
TEXT  COLOUR 
CHARACTER  HEIGHT 
CHARACTER  ORIENTATION 
TEXT PATH 
TEXTAUCNMENT 
CHARACTER  SET  INDEX 
ALT  CHAR  SET  INDEX 
FILL  BUNDLE  INDEX 
INTERIOR  STYLE 
FILL  COLOUR 
HATCH  INDEX 
pattern  INDEX 
FILL  REFERENCE  POINT 

patterntable 

PATTERNSIZE 

COLOURTABLE 

ASPECT  SOURCE  FLAGS 

PICK  IDENTIFIER 

ESCAPE 

MESSAGE 

APPUCATION  data 
SEGMENT  TRANSFORMATION 
SEGMENT  HIGHUGHTING 
SEGMENT  DISPLAY  PRIORITY 
SEGMENT  PICK  PRIORITY 


Page  12 


Add  the  following  (ext  to  the  end  of  sub-ctaiue  4.4.4 

MAXIMUM  VDC  EXTENT  defines  m  extent  which  bounds  the  VOC  extent  values  which  may  be  found  in  the 
raetafile.  It  may  be.  but  need  not  be.  a  closest  bound  in  the  sense  that  it  exactly  equals  the  union  of  the  extent  rectangles 
in  the  metafile. 
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Add  the  following  5ub<lause  after  sub-clause  4.4.6 
4.4.7  Device  viewport  control 

The  device  viewpon  specifies  the  region  of  the  actual  device  drawing  surface  into  which  the  VOC  extent  is  to  be  mapped 
on  interpretation.  VIXT-io-Device  mapping  is  dciemmniud  by  the  VDC  extent,  device  viewport,  and  device  viewpon 
mapping.  This  type  of  transformation  is  restricted  to  allow  only  translation  and  scaling.  No  rotation  or  skew  is 
possible. 

The  position  of  the  device  viewport  is  specified  in  one  of  three  unit  systems  selected  by  DEVICE  VIEWPORT 
SPECmCATION  MODE  elcmenu 
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c.  spot  colour:  OK  (but  check  against  latest  draft  of  ISO  8613  Color  Addendum). 
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by  biction  [0.0  •  1.0]  of  the  avtilable  drawing  surface,  which  allows  reasonable  placement  and  rtiauve  sizing 
of  the  viewport; 

in  miUimeffes  times  a  scale  factor,  which  allows  absolute  sizing  of  images; 
in  physical  device  units. 

The  DEVICE  VIEWPORT  MAPPING  element  may  be  used  to  foice  isoirepic  mapping  even  if  the  specified  VOC  extent 
and  device  viewport  would  not  otherwise  have  led  to  one.  In  such  a  case,  the  VDC  extent  is  mapped  onto  a  subset  of 
the  specified  device  viewport  on  interpretation.  This  subset  is  defined  by  shrinking  either  the  verticaJ  or  honzontaJ 
dimension  of  the  specified  viewpon  as  needed  to  reach  the  required  aipea  riiio.  This  smaller  'effective  viewpon'  is  then 
used  to  defuie  the  cooidinaie  mapping  from  VOC  to  the  device's  coortdinaies.  The  placement  of  the  effective  viewpon 
rectangle  within  the  original  one  can  be  specified.  This  placement  can  be  one  of  left,  right  or  centred  when  the 
shrinking  is  horizontal  and  top,  bottom  or  centred  when  it  is  verticai.  'Left'  and  'bottom'  are  interpreted  as  being 
towards  the  Tirsc  como'  of  the  speafied  DEVICE  VIEWPORT  regardless  of  oiy  mimirini  or  rotation  of  the  vtev.'xirt  on 
(he  physical  device.  These  meanings  are  relative  to  the  rectangle  defined  by  the  non-invened  viewp.>rT. 

For  VDC  Extent  the  coordinates  esn  increisc  or  decrease  fiom  the  Tint  to  the  second  comets.  If  decreasing  coorduiatcs  are 
chosen,  this  will  lead  to  mirroring  or  rotation  of  primttivea. 

The  behaviour  of  primitives  and  geometric  attributes  under  nnsfonna&ons  is  further  described  in  sub-clause  4  6. 

If  both  device  viewport  and  scaling  mode  appear  in  the  same  metafile  then  the  last  specified  is  used.  If  neither  appear 
(hen  the  default  values  for  device  viewport  take  precedence. 

4.4.S  Representations 

The  elements  UNE  REPRESENTATION.  MARKER  REPRESENTATION.  TEXT  REPRESE-NTATION,  HLL 
representation  and  EDGE  REPRESENTATION  are  used  to  set  all  of  the  aoribiue  values  m  a  bundle  table  entry 
at  the  same  time.  The  attributes,  which  may  be  biaidled.  are  described  in  4.7. 
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Add  (he  following  at  the  end  of  sub-clause  4S: 

Some  of  (he  control  elements  may  appear  in  the  Picture  Descriptor  if  this  is  permitted  by  (he  forma)  grammar  for  the 
metafile  version. 
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Add  the  following  text  to  the  end  of  sub-clause  4S.2:  ^ 

There  are  three  different  clipping  modes  for  lines,  matkers  and  edges.  The  required  clipping  mode  is  recorded  in  the 
metafile  with  the  elemenu:  LINE  CUPPING  MODE  EDGE  CUPPING  MODE .  aid  MARKER  CUPPING  MODE 
When  the  CUP  INDICATOR  associated  with  a  graphical  primitive  is  'on',  only  (hose  parts  of  a  graphical  primitive  that 
are  considered  inside  (he  effective  clipping  region  are  rendered  OR  mteqnetaticn.  The  object  clipping  modes  allow  precise 
specification  as  to  how  clipping  is  applied  to  primitives  on  inicrpieuiion. 

Cipping  may  be  either  locus',  'shape'  or  locus  then  shape'.  Concepmally,  a  locns  is  a  mathematical  object  like  a  point 
or  line  segment,  while  a  shape  is  an  area  in  2-diineniionai  apace.  L^araO..  l.or2-diinemional  subsets  of  teal-valued 
2-spaee.  For  markets  and  teal  they  are  poinu.  For  lines  ihqrve  the  iadividnal  Uae  segmenu  or  porrions  of  era.  The 
locus  of  an  ares  is  the  shape  and  the  boundary.  Shapes  reflect  the  leeliration  of  geewetiic  aoribuies  and  ate  generally  2- 
diiiictaionai  subsets  of  real-valued  spKc. 

'Locus'  lipping  is  ap^ied  for  each  portion  of  a  graphic  object  baaed  on  its  mathematical  location  and  is  independent  of 
the  area  it  will  occupy  after  rendering.  For  example,  no  pornon  of  a  line  scgmyau  is  rendered  if  the  ideal  mathematical 
line  tics  outside  the  effective  clipping  region,  (even  if  ia  line  width  asould  cairy  some  portion  of  the  rendering  of  it  into 
the  clipping  rectangle);  no  portion  of  a  marker  is  rendered  if  iu  locanon  lies  ootiids  the  clipping  rectangle. 

If  Locus  cliiyine  iv  used,  the  rendering  is  applied  to  the  locta  of  the  graphic  object.  The  resulting  rendered  shape  areas 
may  dtereffre  esicr.d  nuL-ide  the  effective  clipping  region. 
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Ship#'  ciippmi  u  ippined  »/ier  ih*  alxarsct  muUttvm  of  thapt  ui  d^tot  ccordtniu  tpice.  2-«limCTston*s  pomi  »«t 
iSMxuiMf  with  dw  irtpfuc  oby^a  is  iracnccscd  with  Um  tfr«cu««  chppuii  region,  which  h»a  he«n  oinsformeo  m  ilevicc 
fpMCCL 

Xoctit  dMm  iha|ic'  ciipptng  «Uowi  iIm  tpaaftcatum  that  both  locus  and  shspa  citp^g  ba  applied  lo  graphic  ob>ecu  at 
dewenbed  above.  In  ihis  case  however,  the  randcrad  shape  wiU  not  esuend  ouinda  tha  effective  ciippcng  region  A  thica 
Une  whose  iocus  is  ouuxk  ihe  ciip  wndow  wiU  run  have  eny  ponion  visibtc  even  ,f  lu  li.nc  widift  wonid  carry  tome 
pocuon  of  the  rendering  ouuidi  the  clip  rccungk. 

figwa  ••••••••••  shows  some  aiaiitpks  of  the  effect  of  the  elipptng  modes. 

When  a  wkUi  or  sue  specillctuoii  mode  is  ictiad’.  the  rendesuig  of  shape  proceeds  tn  DC  space  after  et^itcaiion  of  the 
VDCto-Oevice  mapping. 

Fill  and  text  pnmiuvet  do  not  have  tsaociaicd  object  clipping  modes,  (though  the  edge  of  a  fill  pnmtove  and  ihe 
boundary  edges  of  acioaad  figure  da)L  Clipptng  for  nil  prwniuvcs  it  always  consutcni  with  shape  citpptng  (tee  tub- 
clausa  4.6.4  J).  Fm  test  prunaiives.  die  rypt  of  clipping  it  datemmed  by  the  antociwtd  test  petciiion' 

For  string  precision  text,  clipping  proceeds,  on  a  per  soing  basts,  m  a  manner  consisteni  wich  locus 
clipping. 

For  charsetet  preemon  texL  clipping  proceeds,  on  a  per  character  basis.  ji  t  manner  consitic.-i  »nn  .ix  .s 
clipping. 

For  stroke  precinon  text,  the  el'twi  ig  always  prooredi  in  a  manner  consilient  with  ihspe  clippuig 
Note  that  shape  clipping  for  all  text  precisions  u  always  allowed  by  this  Standard. 

Oip  recunglea  applied  to  graphical  ptvniu>t  ,!»menu  within  tegmenu  may  be  lubjtci  to  trisuformaiioni  m  V'DC 
space.  ImamBction  of  dip  recunglea  (urttranafoniMd  or  paufomwd)  may  lead  to  rcsulung  polvgonal  clipping  boundaria 
(see  4.12J), 

FaftiS 

Add  the  following  to  the  list  of  graphical  pruruuve  elemerus  and  to  the  list  of  'me  elements  in  iub<iaus  '  f 

CIRCULAR  ARC  CENTRE  REVERSED 
CONNECTINC  EDGE 

Pa^t  16 

Add  the  following  before  sub-cluse  4.6.1: 

• 

In  addition  to  the  graphical  prirrutive  elctnents  listed  above,  this  Standard  defines  elements  providing  the  dermiiion  of 
'oompotmd  pruniuves'  from  several  of  the  other  graphical  primnives.  The  foUowmi  classes  of  compound  primitives  are 
defined;  'uompoiaid  text'  and  'cloaed  figures .  The  eJements  thei  mey  be  mad  to  specify  compoteid  pruniuves  ere  listed  in 


Tebie  ••••••' 

TeWe  •••••• 

Compound  Frtmiiiva 

Object 

Firai 

Primiiivaai 

Ohv 

Final 

Qaia 

Element 

bidudDd 

Eicmeaits 

Ebmeru 

Compound 

TEXT 

APPEND  TEXT 

APPENDTEXT 

Text 

RESTRICTED 
TEXT  (Note  1) 

(No«2) 

GDP  (Note  3) 

(Note!) 

GDP  (Note  51 

Qosed 

BEGIN 

Line  Primitives 

NEW 

END 

Figure 

Notes: 

FIGURE 

Fill  Primitives 
(Note  4) 

GDP  fNoie  5) 

REGION 

FIGURE 
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1  TIm  (Inal/hoi  (iiuti  flas  is  ‘not  Hnal';  the  primitive  denncs  the  reference  point  of  the  entire  compound  text 
phmitive;  the  text  of  the  priimtive  is  cacnd  in  the  buffer. 

2  The  fiottl/hot  Hnal  (1«|  is  ‘not  ftnaT. 

3  'Hie  fiaalAiot  final  flag  is  ‘not  final';  the  .ott  of  the  primitive  is  entered  in  the  buffer  before  the  compound 
primitive  is  closed. 

4  All  primitives  of  the  identified  classes  may  be  incitided. 

5  Whether  a  GOP  may  eonoibute  to  compound  text  or  closed  figures,  and  whether  or  how  it  specifies  that  the 
compotmd  text  state  or  closed  figure  state  be  opened,  maimaiaad  or  closed,  is  specified  with  the  dermiuon  of 
the  GOP  in  the  Inienutianel  Register  of  Griph^  lions. 

Graphical  primitive  elements  end  compound  primitive  elements  may  be  subject  to  transformation  in  VDC  space 
(sagmeni  and  copy  transformation.  4.12.4.2  and  4.12J).  Such  a  txanaformation  may  change  the  shape  of  some 
primidves.  If  there  is  a  skew,  a  primitive  initially  specified  as  a  rectangle  may  become  a  parallelogram.  If  there  is  an 
anisotropic  scaling,  s  piimidvc  initially  specified  as  a  csicle  may  become  an  ellipse.  Note  that  the  shape  of  markers  is 
exempt  from  such  trsnsfarmaiians. 
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Sub-clause  4.6.1. 1  add  the  following  text  to  the  paragraph  descibing  CIRCULAR  ARC  xxx 
A  nyme  direction  «e  can  also  be  specified,  this  is  descibed  in  5.6.20 
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Add  the  following  at  the  end  of  sub-clause  4.6.1. 1 

CONNECTING  EDGE  A  line  segment  connecting  the  last  point  of  the  preceding  line  element  to  the  next  point  is 

gcnoaied  during  the  construaion  of  s  closed  figure.  The  next  point  is  either  the  first  point  of  the  next  line  element  or 
the  cunrem  closure  point. 
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Add  the  following  st  the  end  of  tub-clause  4.6.U 

In  version  two  metafiles,  line  clipping  is  controlled  by  the  LINE  CUPPING  MODE  element,  which  can  have  one  of 
the  following  values;  locus',  'shi^',  or  locus  then  sh^w'.  However,  clipping  only  applies  if  the  CUP  INDICATOR  is 
‘on. 

For  locus'  clipping,  the  mathematical  locus  of  the  line  is  dipped  at  the  intersection  with  the  clip  rectangle  before  shape 
reiKkring  is  applied.  Hence,  pen  of  the  shape  of  a  line  may  appear  ouuide  the  clip  rectangle. 

For  'shape'  cUpping,  the  diape  of  the  roidered  line  is  dipped  to  the  iniarscetion  with  the  dip  rectangle,  that  is  nothing  is 
drawn  outaidc  tha  dip  raeiangle. 

For  locus  then  shape'  clipping,  the  mathematical  locus  of  the  line  is  dipped,  u  with  locus  clipping,  and  then 
subsequently  the  renderad  sh^  of  the  dipped  locus  is  again  clipped.  Note  ihu  sinee  the  maihematkal  locus  of  the  line 
may  Iwe  changes  as  a  leaull  of  locus  clipping,  subsequem  shape  rendering  and  clipping  may  produce  a  different 
appearance  of  a  line  from  either  of  the  oihor  two  clipping  modes. 

If  the  lina  width  is  raeanrad  in  VDC  uniu  it  is  subject  »  VDC-to-Device  mappmi  (4.4.7)  as  well  as  to  both  segment 
and  copy  ttansformaiion  (4.12.4.5  and  4.12J).  Note  that  the  auae  locus  of  an  arc  is  subject  to  these  transformations. 
In  case  of  an  anisotropic  mapping  or  armsformation  the  tindeied  width  of  the  line  wiU  change  with  Jie  direciion  of  the 
line  segment.  If  the  Ite  width  is  specified  as  a  scale  factor  it  is  not  affected  by  any  transfoimations. 
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Sulxlause  4.6.2J:  Add  the  following  at  the  beginning  of  the  sub-clause; 
The  following  discussion  applies  to  version  I  metafiles. 
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Sub-clause  4.6^:  ai  (he  end  of  (he  first  paragraph  change  'is  not  standardized.'  (o  the  following; 
is  not  standardized  for  venion  I  metafiles. 
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Sub-clause  4.6.2J:  Add  the  following  at  the  end  of  the  sub-clause: 

In  venion  2  metafiles,  marker  cUpping  is  etmeroUed  by  the  MARKER  CLiPPINC  MODE  element  which  can  have  one 
of  the  following  values:  locus’,  'shape'  or  locus  then  shape'.  However,  clipping  applies  only  if  the  CUP  INDICATOR 
is  on'. 

For  locus'  cEpping.  the  mathematical  locus  of  the  markers  (that  is  the  specifying  points),  are  clipped  at  the  intersection 
with  the  cEp  rectangle  before  shape  tendering  is  appEed.  Hence,  pan  of  the  shape  of  a  marker  may  appear  outside  the 
cEp  rectangle.  However  the  marte  is  visiUe  iE  and  only  if.  its  specifying  point  is  within  the  clip  rectangle 

For  'shape'  clipping,  the  shape  of  (he  rendered  marker  symbols  are  cEpped  to  the  intersection  with  (he  clip  rectangle,  that 
is  nothing  is  drawn  outside  the  cEp  rectangle.  Portions  of  the  marker  symbol  may  appear  iruide  the  clip  rectangle  even 
(hough  the  marker's  locus  is  outside. 

For  locus  then  shape'  clipping,  the  mathematical  locus  of  the  markers  are  clipped,  as  with  locus  clipping,  and  then 
subsequently  the  rendered  shape  of  the  markers  are  again  clipped. 


If  the  marker  size  is  measured  in  VDC  tmits,  it  is  subject  to  VDC-to-Oevice  mapping  (4.4.7)  as  well  as  to  both  segment 
and  copy  transformation  (4.12.4.S  aid  4.12.5).  llie  shape  of  markers  is  never  affected  by  transformauoru.  for  example  a 
circle  used  as  a  marker  type  shaO  always  appear  as  a  circle.  Only  the  marker  size  may  be  transformed.  For  this  purpose, 
conceptually,  vectors  with  the  length  marker  size  end  arbitrary  orientations  are  tranifoimed;  the  resulting  marker  sue  is 
determined  by  the  orienuiion  of  the  vector  which  mazimtzes  the  length  under  the  cransformation  (eurlidean  norm  of  2z2 
traisformaaon  matrix). 

If  the  marker  size  is  specified  as  a  scale  factor  it  is  not  affected  by  any  nnsformations. 

PagtIS 


Add  the  following  at  the  end  of  sub-clause  4.6 
Cipping  of  text  strinp  is  described  in  4.7.6. 

Hie  vectors  specified  by  the  CHARACTER  ORIENTATION  element  (4.7.6)  are  subject  to  the  VDC-to- Device  mapping 
u  well  as  lo  bath  segment  and  copy  transformation. 
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Add  the  followmg  at  the  end  of  sub-claiuc  4.6.4.5 

Edge  cEpping  is  controlled  by  the  EDGE  CLIPPING  MODE  element,  which  has  the  same  enumerations  as  LINE 
CLIPPING  MODE.  Edges  are  cEpped  in  the  same  way  that  lines  are  cUpped.  see  4.6.  U 
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Add  the  following  sub-clause  after  sulxlausc  4.64.S: 

4.6.4.6  Tratuformatlon 

The  entire  locus  of  rectangles,  circular  and  elliptical  ftlled-area  elements  is  subject  to  VDC-to-Oevice  mapping  (4  4.7). 
segment  and  copy  transformations  (4.12.4.5  and  4.125).  These  elements  may  not  therefore  retain  ihcir  specified 
geometry  after  transformation. 

The  vectors  of  the  PATTERN  SIZE  element  are  subject  to  ail  transformations. 

The  edge  widths  are  treated  in  exactly  the  same  way  as  line  widths  (4  6.1.3). 
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Add  the  foUowing  wb-cUiue  after  sub-ctause  4.6.7 

••••.•••■•••■•••••to  1,,  changed  ia  line  with  CGI  ■  this  It  the  Kona  CGI  text  •• 
4.6.1  Closed  figures 


3.9.5. 1  Construction  of  closed  figures.  A  closed  figure  is  a  fill  type  compound  graphic 
object  which  the  client  constructs  on  the  device  side  of  the  interface  by  invoking  BEGIN 
FIGURE,  an  ordered  sequence  of  line  and  fill  primitives  (and  optionally  attributes  and  NEW 
REGION  functions),  and  END  FIGURE.  Edge  attribute  values  are  associated  locally  with  the 
edge  portions,  and  fiii  attribute  values  associated  globally  with  the  complete  graphic  object: 
in  addition,  certain  general  attribute  values  are  associated  locally  with  edge  ponions  and 
globally  for  the  interior  of  the  fill  object  The  erttire  graphic  object  then  travels  through  the 
CGI  pipeline,  and  is  rendered  as  a  single  unit  with  the  parity  fill  algorithm  described 
elsewhere. 

3. 9.5.1. 1  Closure  Point.  The  first  point  of  the  first  line  primitive  in  a  new  region  is  the 
closure  point  for  that  region.  The  Virtual  Device  retains  this  closure  point  for  use  in  closing 
the  region.  When  the  region  is  closed  (with  a  NEW  REGION  or  END  FIGURE  function,  or  by 
invoking  a  fill  primitive  which  begins  a  new  region),  a  line  segment  from  the  last  point  of  the 
last  line  primitive  in  the  region  to  this  closure  point  is  added  by  the  Virtual  Device  lo  the 
figure,  unless  these  points  are  already  coincident 

3.9.5. 1.2  Regions.  The  dosed  figure  consists  of  one  or  more  regions;  a  region  has  a  closed 
boundary  which  may  be  concave,  convex,  and  self  crossing.  A  region  is  formed  either  by 
invoking  a  fill  type  primitive  in  FIGURE  OPEN  state  (which  closes  the  last  region  and 
contributes  one  or  more  complete  regions),  by  invoking  NEW  REGION  to  start  new  regions  to 
be  formed  from  line  primitives,  or  by  a  final  invocation  of  END  FIGURE.  A  closed  figure 
constructed  from  only  line  primitives  without  use  of  NEW  REGION  consists  of  a  single  region. 

The  NEW  REGION  function  may  appear  anywhere  in  the  dosed  figure,  if  the  current  region  ts 
dosed,  the  function  is  ignored,  if  the  current  region  is  open,  an  implicit  boundary  ponton  is 
added  from  the  last  point  of  the  last  primitive  to  the  current  closure  point  unless 
CONNECTING  EDGE  has  been  invoked  after  the  last  line  primitive,  in  which  case  an  explicit 
boundary  portion  and  edge  portion  is  added  instead. 

3.9.5.2  Boundaries  and  Edges.  Each  region  consists  of  a  combination  of  implicit  boundary 
portions  and  edge  portions. 

3.9.5.2.1  Explicit.  Explidt  boundary  portions  and  edge  portions  are  those  added  by  client 
invocation  of  primitives  in  state  FIGURE  OPQI.  These 
are  generated  in  the  following  situations; 

>  for  fill  primitives  other  than  POLYGON  SET,  the  complete  edge  becomes  an  explicit 
boundary  portion  and  edge  portion  in  the  dosed  figure. 

•  for  line  primitives,  those  portions  which  would  be  rendered  outside  of  state  FIGURE  OPEN 
become  explicit  boundary  portions  and  edge  portions. 
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•  For  DISJOINT  POLYLINE,  in  particular,  only  tha  sagmants  from  tha  first  point  to  tha  sacond 
point,  from  tha  third  point  to  tha  fourth  point  and  so  on,  bacoma  explicit  boundary  portions 
and  edge  portions  whan  incorporated  into  closed  figures. 

•  A  CONNECTING  EDGE  primitiva  which  precedes  an  action  which  would  normally  have  added 
an  implicit  boundary  portion  to  tha  figure  either  to  close  a  region  (including  closing  the  figure 
itself)  or  to  connect  two  line  primitives  results  in  tha  portion  added  being  an  explicit 
boundary  portion  and  edge  portion.  CONNECTING  EDGE  preceding  or  following  DISJOINT 
POLYLINE  or  POLYGON  SET  does  not  affect  tha  interpretation  of  those  functions  with  respect 
to  boundaries  and  edges. 

Edge  portions  taKe  associated  edge  attribute  values  from  tha  state  list;  as  these  state  list 
entries  can  be  changed  between  the  primitives  that  result  in  edge  portions  in  FIGURE  OPEN 
state,  each  edge  portion  has  a  distinct  set  of  attribute  values  associated  with  it. 

3.3.5.2.2  Implicit.  Edge  attributes  are  never  associated  with  implicit  boundary  portions. 
Implicit  boundary  portions  are  only  rendered  for  interior  style  hollow  and  are  a  special 
representation  of  the  interior,  not  a  representation  of  any  portion  of  the  edge. 

Implicit  boundary  portions  are  added  by  the  CGI  device  to  the  figure  definition  under  the 
following  circumstances: 

•  invocation  of  NEW  REGION,  END  FIGURE,  or  a  fill  primitive  when  the  current  region  has  not 
been  explicitly  dosed  and  CONNECTING  EDGE  has  not  been  invoked  since  the  last  line 
primitive:  an  implicit  boundary  portion  is  added  from  the  last  point  of  the  last  primitive  to 
the  eument  dosure  point  to  close  the  region. 

•  when  the  last  point  of  the  preceding  line  primitive  is  not  coincident  with  the  first  point  of 
the  current  line  primitive,  an  implidt  boundary  portion  is  created  to  connect  the  last  point  of 
the  preceding  line  primitive  to  the  first  point  of  the  current  line  primitive. 

•  the  portions  of  a  DISJOINT  POLYLINE  which  would  not  normally  be  rendered  (i.e.,  from  the 
second  point  to  the  third  point  from  the  fourth  point  to  the  fifth  point,  and  so  on)  result  m 
implicit  boundary  portions.  (These  are  additional  to  the  ones  which  may  be  added  to  connect 
to  a  preceding  or  following  line  primitive  or  to  effect  region  closure  after  the  DISJOINT 
POLYUNE) 

•  tha  portions  of  polygon  sat  as  described  below. 

3.9.5.2.3  Conditions  under  which  no  boundary  or  edge  is  added.  No  boundary  or  edge  portion 
is  ever  created  connecting  two  regions,  regardless  •  of  how  those  regions  were  created  or 
closed. 

3.9.5.3  Contribution  of  Primitive  Functions  to  the  Rgure. 

3.9.5.3.1  Contribution  of  Une  Functions  to  the  Rgure  [continue  with  what  was  3.9. 5.1.1 
Add  this  before  final  paragraph  of  the  section:] 

COf^CCnNGSDGE 

If  the  region  is  open,  the  start  point  of  the  connecting  edge  is  the  last  point  of  the  last  line 
primitive,  and  the  end  point  of  the  connecting  edge  is  either  the  first  point  of  the  following 
primitive  or  the  current  closure  point  as  described  above.  If  tha  connecting  edge  would  be  of 
zero  length  (i.e..  if  the  two  points  it  connects  are  coincident),  the  function  is  ignored.  As 
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with  other  line  primitives,  the  edge  attribute  values  in  affect  at  the  time  it  is  invoked  are 
associated  with  any  edge  portion  generated  by  this  function. 

If  the  current  region  is  not  open,  invocations  of  the  CONNECTING  EDGE  function  are  ignored 
(Le..  CONNECTING  EDGE  cannot  be  used  to  connect  regions). 

CONNECTING  EDGE  is  a  primitive,  not  a  modal  setting;  it  must  be  invoked  once  for  each 
connecting  edge  desired  in  the  figure,  and  once  used,  no  longer  applies  to  subsequent 
opportunities  for  explicit  connection. 

Invoking  CONNECTING  EDGE  multiple  times  after  a  line  primitive  results  in  the  last  instance 
(with  its  associated  attributes)  being  used. 

[continue  with  last  paragraph  of  section] 

3.9.5.3.2  Contribution  of  Fill  Functions  to  the  Figure,  [replaces  3. 9.5.1. 2]  Each  fill 
primitive  contributes  a  complete  region  to  the  figure  (POLYGON  SET  may  contnbute  more 
than  one),  after  first  closing  the  current  region  if  it  is  open.  The  CGI  device  performs  an 
implicit  NEW  REGION  before  and  after  a  fill  primitive  invtSied  in  FIGURE  OPEN  state  (i.e..  a  fill 
primitive  leaves  the  current  region  dosed,  and  the  next  primitive  begins  a  new  region) 

The  undipc^d  boundary  of  each  fill  primitive  contributes  to  the  undipped  boundary  of  the 
dosed  figu the  locus  of  its  imerior  does  not  affect  the  boundary  definition. 

Contribution  of  POLYGON  SET  to  figure  construction: 

•  A  POLYGON  SET  is  cortsidefed  to.  contribute  one  or  more  complete  regions.  If  the  current 
region  has  not  been  dosed,  an  implicit  NEW  REGION  is  performed  before  the  POLYGON  SET  is 
added  to  the  figure  definition.  If  the  POLYGON  SET  does  not  end  with  a  point  whose  edge-out 
flag  is  *doss  visible*  or  *dose  invisible*  .  an  implidt  NEW  REGION  is  performed  after  the 
POLYGON  SET. 

•  Sequences  of  points  with  edge-out  flag  *visibie*  are  treated  as  if  they  were  polylines, 
terminating  with  the  first  point  with  a  different  edge-out  flag.  Each  such  polyline  becomes 
an  edge  portion  of  the  boundary  of  the  figure.  The  edge  attribute  values  in  effect  when 
POLYGON  SET  is  invoked  are  associated  with  any  edge  portion  added  in  this  way. 

•  Sequences  of  points  with  edge-out  flag  *1rtvi8ible*  contnbute  implicit  boundary  portions 
which  are  polylines  joining  the  points  in  the  sequence,  but  not  edges.  Edge  attribute  values 
are  not  associated  with  these. 

•  Points  with  edge-out  flag  *dose  invisible*  generate  the  equivalent  of  a  NEW  REGION, 
generating  an  implidt  boundary  portion  from  this  point  to  the  current  closure  point  if  these 
are  not  coincident,  and  dosing  the  current  region. 

•  Poims  with  edge-out  flag  *dose  visible’  generate  the  equivalent  of  a  CONNECTING  EDGE 
followed  by  a  NEW  REGION,  resulting  in  an  edge  portion  from  this  point  to  the  current  closure 
point  if  these  are  not  coincident  The  edge  attribute  vaiuet  in  effect  when  POLYGON  SET  is 
invoked  are  associated  with  any  edge  portion  added  in  this  way. 

•  POLYGON  SET  does  not  affect  the  value  of  the  edge  visidlity  value  in  the  state  list. 

3.9.5.3.3  GOP.  A  GOP  which  is  defined  as  a  line  type  primitive  must  specify  which  is  the 
first  point  and  the  last  point  in  its  point  list,  with  respect  to  closed  figure  construction. 
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Such  GOP’s  are  assumed  to  contribute  to  a  closed  figure  a  boundary  corresponding  lo  the 
undipped  locus  which  would  be  rendered  if  the  function  were  invoked  when  not  in  FIGURE 
OPEN  state;  any  other  behaviour  shall  be  documented  explicitly  tn  the  GDP  descnption.  A 
GOP  which  is  defined  as  being  a  Till  type  primitive  function  is  treated  as  in  the  previous 
section;  any  variation  or  special  handling  in  state  FIGURE  OPEN  shall  be  explicitly  documented 
in  the  GDP  description. 


3.9.5.4  [replace  3.9.S.1.4>6]  Association  of  attributes. 

3.9.5.4.1  Local  attributes  are  those  associated  with  each  edge  portion,  which  can  vary  from 
edge  portion  to  edge  portion  within  the  compound  object.  The  local  attnbuies  for  closed 
figures  are  the  set  of  edge  attributes. 

3.9.5.4.2  Global  attributes  are  those  associated  with  the  compound  object  as  a  whole  rather 
than  its  comportsnt  parts.  The  functions  which  set  their  state  list  values  may  be  invoked 
during  FIGURE  OPEN  state,  and  have  their  usual  effect  on  the  corresponding  state  list  entries. 
The  values  associated  with  the  closed  figure  are  those  in  the  state  list  when  END  FIGURE  is 
invoked  to  complete  the  object  formation  (even  in  the  event  of  figure  buffer  overflow  during 
construction).  Global  attributes  of  closed  figures  are  the  set  of  fill  attributes.  CLIP 
INDICATOR.  CLIP  RECTANGLE,  EDGE  CLIPPING  MODE,  and  PICK  ID.  In  particular,  note  that  Clip 
Rectangle  and  Clip  Indicator  are  associated  with  the  compound  object,  but  not  applied  during 
graphic  object  formation  (the  graphic  object  is  formed  from  the  undipped  locus  of  each 
pnmitive  function  invoked  in  FIGURE  OPEN  state). 

3.9.5.4.3  There  is  a  set  of  attributes  which  are  local  attributes  with  respect  to  the  edge 
portions,  but  which  are  associated  globally  with  the  interior.  This  set  consists  of  AUXILIARY 
COLOUR  (and  its  corresponding  colour  sefectton  mode  in  which  set),  TRANSPARENCY,  and 
DRAWING  MODE  In  order  to  use  a  different  value  for  the  interior  from  that  for  any  of  the 
edge  portions,  the  appropriate  attribute  function  should  be  invoked  just  prior  to  invoking  END 
FIGURE  with  the  value  lo  be  used  for  the  interior. 

. •***end  CGI  text  . . 

examples  need  redoing  -  liaison  with  CGI  needed  •••••••••••■••••• 

4.4.S.8.  Examples 

Note  The  ciesr  taxi  encoding  is  used  here  for  illustration  purpose. 

••••••••“•need  updating  •••••••••••••••• 


Example  1. 


This  example  uses  the  Arc  Centre  command  u>  crease  a  doughnut  shape.  The  following  commands  are  used 


BeginHg; 

ArcCtr50J01.0  1.0  45; 

AxeCor5(UO  1,0  1.0  40; 

EndFig: 

Note  that  this  figure  can  also  be  obtained  by  the  sequence 

Begin  Fig; 

Circle  50J0  45; 

Circle  SOJO  40; 

EndFig; 
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Example  2 


Thix  example  uses  the  Elliptical  Arc  osmmand  to  creat/r  a  box  with  rountied  comen.  The  foUowmg  commands  are  used: 
BeginFig; 

%  All  straight  edges  cotmecting  the  elliptical  arcs  % 

%  are  drawn  as  implicit  edges  % 

ElIipArc  75.82  90.82  75.110  1.0  0.1; 

EllipArc  25.82  25. llO  1 0.82  0. 1  - 1 .0; 

EllipAfc  25.38  10.38  25.10  -1.0  0.4; 

BlipAre  75 J8  75.10  90.38  0.4  1.0; 

Eni^ig: 


Example  3. 


This  example  uses  the  Bliptical  Are  command,  showing  how  CDP  order  can  be  used  to  diange  the  sweep  direction.  The 
lines  indicate  the  short  angles  between  the  GDP's.  The  following  commands  are  used: 

BeginFig: 

%  All  straight  edges  connecting  the  elliptical  ares  % 

%  SIC  drawn  u  implicit  edges  % 

%  The  flni  arc  is  swept  in  a  counterclockwise  direction  % 

ElUpAre  6OJ0  60.100  - 10.50  O.I  0.4: 

%  The  second  are  is  swept  in  a  clockwise  direction  % 

ElIipArc  60J0  60.10  OJO  0.4  0.1; 
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Endfig; 


Pait39 

Add  the  following  sub-dausa  after  suiv*.  .^usc  4.7.8 

4.7.9  Pick  Identifier 

The  Pick  Identifier  is  associated  with  graphical  pnmiuvc  elcoientt  within  tcgn»nu  (tee  clause  4.12).  It  is  the  only 
attribute  element  which  does  not  afTea  the  tppevnee  of  a  graphical  primitive  elemetit.  It  merely  esublishes  *  means  of 
tdemiftcaiion  of  primitives  within  segmenu  u  metafile  intopretation.  PICK  IDENTTFTER  has  no  graphical  effect  and  is 
available  for  application  dependent  communication  between  interpmen  md  generators. 

4.7.10  Global  and  local  attributes  and  conlrola 

For  the  purpose  of  compound  primitive  definition  (see  4.6)  a  further  clauification  of  attributes  and  control  elements  into 
'global'  and  local'  attribute  and  control  elements  is  introduced.  Global  etemenis  apply  to  compound  primitives  as  a 
whole,  while  local  elements  apply  sepsatly  to  the  component  graphical  primitives  of  a  compound  primiuve. 

Page  40 

Add  the  following  sub-clauses  after  sulxlause  4.1 1 ; 

4.12  Segment  elements 

4.12.1  Introduction 

In  the  CGM,  graphical  primitive  elements  or  oimpound  primitives,  attribute  setting  elements  and  certain  control 
elements  may  be  grouped  in  segments  as  well  as  being  invoked  outside  segmenu.  They  may  also  be  defined  as  global 
segments,  within  the  Metafile  Descriptor,  and  can  then  be  copied  into  a  picnire.  Each  segment  is  identified  by  a  unique 
segment  identifier.  Segmenu  may  have  the  soributes: 

a.  transfonnaiion: 

b.  highlighting; 

c.  display  and  pick  priority; 

These  may  be  defined  at  segment  definition  time,  before  the  fust  primitives  of  the  segment,  and  shall  not  be  changed 
thereafter  for  static  picture^apase  metafiles.  * 

Only  eJemenu  stored  iiuide  segmenu  are  affected  by  the  segment  attributes. 

The  segmem  elemenu  are: 

COPY  SEGMENT 
INHERITANCE  FILTER 
CLIP  INHERITANCE 
SECMENTTRANSFORMA'nON 
SEGMENT  HIGHUCHIING 
SEGMENT  DISPLAY  PRIORTTY 
SEGMENT  nCK  PRIORITY 

BEGIN  SEGMENT  and  END  SEGMENT  are  delinu;sr  elemenu  rather  than  segment  elemenu. 

4.12.2  Global  and  local  sagments 

There  are  two  types  of  segmenu:  local  segmenu  and  global  segmenu.  Both  contain  ptimiiives  and  attributes  which  can 
be  manipulated  in  the  manner  described  above.  Local  Segmenu  have  no  esistence  beyond  the  botmds  of  the  picture  body 
m  which  they  are  defined.  Defining  a  local  segmem  in  a  picture  automadcaHy  includes  that  segment  m  the  picture  s 
image.  In  contrast  global  segmenu  can  be  referenced  by  any  of  the  pictures  in  the  metafile  in  which  they  arc  defined. 
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4.12J.1  Location  of  and  access  to  global  scgncats. 

A  global  segment  is  delimited  by  the  BEGIN  SEGMENT  and  END  SEGMENT  elements.  Global  segments  are  defined 
in  the  Metafile  Descriptor.  They  are  not  a  pan  of  any  pknire  within  the  metafile.  They  must  be  accessed  from  within 
individual  pictures  by  the  COPY  SEGMENT  {4.12J)  elemenL  The  COPY  SEGMENT  element  incxnporates  the 
segment  into  the  open  picnire  in  the  ^  .me  way  for  both  local  and  global  segments. 

4.12^  Allowable  alemcnu  in  MD  and  GSS  states 

BEGIN  SEGMENT  is  the  only  segment-related  element  that  is  allowed  within  the  Metafile  Descriptor  State  (MOS)  (see 
TaUe  3(a),  the  Metafile  State  Table).  BEGIN  SEGMENT  chsiges  the  state  to  Global  Segment  State  (GSS). 

4.12.2J  References  to  global  segments 

Within  pictures,  no  elements  are  allowed  that  would  modify  the  contents  or  default  appearance  of  global  segments  (see 
Table  3(a)).  This  restriction  preserves  the  logical  independence  of  pictures  and  the  ability  to  randomly  access  piciures. 
The  only  allowable  references  to  global  segments  within  pictures  are  by  using  the  COPY  SEGMENT  element. 

4.12.2.4  Association  of  control  and  attribute  ciemenu  and  attribute  clcmenu  with  primitives 

Inside  segments 

The  current  modal  values  of  control  and  attribute  elements  are  associated  with  the  primitives  inside  local  segments.  The 
modal  values  esubi's-hed  by  setting  control  or  attribute  elements  within  a  segment  remain  outside  the  segmeru  tmtil  they 
«e  esplidtlv  ch*  iged. 

ContT'l  rnu  attribute  elements  are  bound  in  global  segments  u  they  are  in  local  segments.  Upon  the  occurrence  of 
BEGiN  .METAFILE,  every  element  that  is  modally  defined  and  bound  to  primitives  (Metafile  Descripior  elements 
drOning  modes  and  precisions.  Pienn  Descriptar  elements.  Control  elemenu  Attribute  elements  and  Segment  Control 
elemenu)  has  a  def^  value.  Conceptually  the  set  of  all  of  these  define  a  “Modal  Stale  List*. 

Hie  Metafile  Descriptor  is  processed  sequentially.  Throughout  the  Metafile  Descripior.  modal  MD  elemenu  modify  the 
MD  entries  is  the  state  list  and  occurrences  (possibly  multiple)  of  the  METAFILE  DEFAULTS  REPLAC^ENT 
elemcss  allow  manipnlaiion  (ouuide  of  (3SS  state)  of  the  rest  of  the  modal  elemenu  (as  well  as  eaplicitly  changing  the 
defaulu).  Within  GSS  state  the  allowable  modal  elemenu  (control,  attribute,  and  segment  attribute)  also  alter  the 
eoniann  of  the  Modal  State  List.  The  vduas  of  modal  elemenu  that  are  in  effect  upon  BEGIN  PICTURE  «e  the  default 
values  for  that  pktnte,  whether  they  are  implicit  (defined  in  the  Standard)  or  explicit  (that  is  by  values  setin  the  Metafile 
Defaulu  Replaeemem). 

4.12J  Delimiting  and  naming  segments 

The  conienn  of  a  sepnent  are  delimited  by  the  elemenu  BEGIN  SEGMENT  and  END  SEGMENT.  The  elemenu  in 
between  these  two  deiuntters  sre  a  part  of  that  segment.  Each  segment  has  an  identifier  associated  with  it.  No  two 
global  segmenn  may  have  the  same  idenuTier  and  no  local  segment  may  have  an  identifier  which  ia  the  same  as  either  a 
local  segment  in  the  same  picture  or  the  same  as  a  global  segment. 

4.12.4  ScgncRt  attributes 
4.12.4.1  IntrodurtloB 

The  segment  attribuiea  Miodatad  with  each  segment  control  its’  display.  Sagmem  ataribuiaa  can  bt  set  only  while  the 
segmmi  is  open.  These  may  be  defined  at  segment  definition  time,  only  before  the  first  primitives  of  the  segment  and 
tttay  not  be  changed  ihcreaAcr.  When  a  segmem  is  opened  with  the  BEGIN  SEGMENT  element  the  segment's  attributes 
art  set  to  thek  default  vahica.  Segmeru  aonditea.  if  set  shall  be  set  immediately  after  tha  BEGIN  SEGMENT  element 
and  before  any  other  type  of  element  This  structure  ia  shown  below. 

BEGIN  SEGMENT  (Segment  identifier) 

Segment  atnibuies 

Allowed  primitives,  aliribuics  and  control  clemeius  in  any  order 
-  END  SEGMENT 


4.12.4.2  Segment  transformation 
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The  segraeu  mmfonnaxioii  is  a  coordinate  iransfonnatioa  associated  with  each  scfmeu  and  applies  to  ail  gnphicat 
primidva  in  the  idauined  segment  and  will  be  used  on  imerproation.  Qipping  racunglea  ant  not  transfonned  by  the 
segme«  transfonnation.  It  allows  scaling,  translation,  and  reuiion  of  Mqpacmt  to  be  defined  dining  segment  deTmiiian. 

The  segment  transfotmation  is  a  transformation  of  VDC  space  to  VDC  space  and  is  distinct  from  the  VDC-io<Oevice 
mapping  which  is  a  transfiarmadon  of  VDC  space  to  device  oootdinaies. 

The  transformation  attribute  of  a  segment  may  be  defined  by  the  SECMENTTRANSFORMATTON  element  during  the 
segmem  definidon.  A  segment  transformation  is  represented  by  a  2x3  matrix,  composed  of  a  2x2  scaling  snd  rotation 
poitkm,  ind  a  2x1  tianslision  portion.  The  defauit  segment  Erar^ormadon  is  represented  by  the  idendty  irtnsformadon. 
If  the  SEGMENT  TRANSFORMATION  element  is  not  stored  in  the  metafile,  then  ail  co^mate  dau  is  mapped  using 
only  the  VDC-io-Oevicc  mapping.  If  the  SECMENTTRANSFORMATTON  is  stored  in  the  metafile,  it  is  applied 
before  the  applicaiioa  of  the  VDC-io*Oevice  mapping. 

The  use  of  segment  transfomuuons  may  produce  coordinates  that  caimot  be  expressed  within  the  VDC  range.  This  is 
handled  in  an  interpreudon  dependent  way. 


4.12.4J  Segment  highlighting 

Segmem  highlighting  can  take  one  of  two  values.  NORMAL  and  HIGHLIGHTED.  The  setting  of  this  attribute  selects 
one  of  these  two  states  for  the  segmeriL 

4,12.4.4  Segment  display  priority 

The  display  priority  toribuie  of  a  segment  determines  how  overlapping  segments  are  displayed.  Segments  with  higher 
display  priorities  will  be  displayed  as  if  they  were  in  fiont  of  segments  with  lower  display  prioriues.  The  segment 
display  priority  may  be  nonrnalized  to  the  candmious  range  of  resJ  numbers,  zero  lo  one,  by  applying  the  minimum 
extent  and  maximom  extent  values  provided  by  the  Metafile  Descriptor  element  SEGMENT  PRIORITY  EXTENT. 
Interpreistion  of  SEGMENT  PICK  PRIORITY  has  no  graphical  effect.  Its  generation  and  interpretation  axe 
implementadan  depcndoiL 


4.12.4J  Segment  pick  priority 

The  pick  priority  attribute  of  a  segment  is  used  to  resolve  the  picking  of  segments  which  overlap.  The  segment  pick 
priority  may  be  normalized  to  ihn  continuous  range  of  real  immbers.  zero  to  one.  by  applying  the  mmimum  extent  and 
maximum  extent  values  provided  by  the  Metafile  Descriptor  element  SEGMENT  PRIORITT  EXTENT. 

4.12.5  Copy  segment  and  Inheritance 

The  COPY  SEGMENT  inserts  the  elements  of  the  referenced  segment  into  the  picnire  at  the  point  of  occtarence  of  the 
eiemenL 

The  elemena  copied  may  be  altered  in  a  variety  of  ways: 

a.  The  inheritance  filter  mechanism  controls  whether  individual  auribuie  values  are  reapplied  u>  the  elements 

b  The  clip  inheritance  mechanism  controls  whether  the  primitives  in  the  segment  ate  clipped  to  the  cunem  clip 

leetangla  or  to  a  combinitian  of  the  emrent  and  the  segment  clipping  rectangles. 

c.  The  piimiiive  eiemems  are  transfonned  by  the  copy  segmem  transformation  and  optionally  by  the  segmem 
transfotmation  of  the  copied  segment  according  to  the  rales  for  uinsfatmatkm 

COPY  SEGMENT  has  a  transformatien  matrix  as  a  parameter.  The  copy  segmou  transfoimatian  is  applied  to  graphicai 
primitives  before  they  are  copied.  This  alto  applies  to  clipping  rectangles  in  the  segment  (see  fa^ow).  Gr^shicai 
primitives  may  be  tran^ormed  to  alter  their  location,  size,  and  orientation. 

A  segmem  may  be  referenced  by  the  COPY  SEGMENT  dement,  either  within  a  piemre  or  in  a  global  segmenL  The 
attributes  associated  on  interpretation  can  be  those  bound  to  the  segmem  being  copied,  or  can  be  imposed  by  the 
inclusion  of  the  INHERITANCE  FILTER  elemenu 

The  clipping  associated  with  a  segment  can  be  that  associated  with  the  picture  u  the  time  of  the  copy  or  can  be  a 
combination  of  the  current  clipping  and  the  segment  clipping  when  the  CLIP  INHERITANCE  element  is  used. 
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The  tahchmce  filter  nwchHusm  ■ilowt  the  um  of  the  cumnt  v«lita  of  auribuusi  end  oonsoli  to  b*  Mtocieud  with  the 
copied  segmeitt  in  piece  of  the  aonbiites  end  concroie  bound  to  the  pnmitives  when  the  segment  wee  ocaied.  The 
iltnbuies  end  controls  to  be  essociited  with  the  segment  cen  be  ell  euributes  or  cen  be  e  subset  of  euribuies.  The 
eoributes  end  ccnitols  ere  selected  using  the  INHERITANCE  FILTER  element.  The  euributes  end  eontroU  cen  be 
selected  using  indNiduel  or  group  nemes  for  ettribuies.  controls  end  AiFs.  The  elements  •''hkh  cen  be  selected  ere 
shown  in  Teble  •'"  -•••  for  euributes  end  controls  mi  in  Teble  ••••  for  ASFs. 

The  individuel  element  nemes  es  wdl  es  the  group  nemes  ere  those  in  the  teble  showing  auribute  groups  below. 

If  en  eiiribuie  or  group  of  ethibutes  designated  in  the  filter  selection  list  is  set  to  stele  Jisi".  griphics  objects  Inherit  ihsi 
eoribute  or  group  of  saiibutes  from  the  current  model  values  when  a  sepncnt  is  copied. 

If  m  esribttU  or  group  of  etmbuies  designated  in  the  filter  selection  list  is  set  to  ’segment',  that  attribute  or  group  of 
^butes  is  unaffected  (in  ell  graphics  objects  employing  them)  by  the  corresponding  current  state  list  when  a  segment 
IS  copied. 

The  default  inheritance  filter  setting  value  is  segment'  for  ail  auributes  and  controls. 


Table 


Inheritance  Filter  Selection  Names  for  Attributes 


Attribute  Group  Name 


Individual  Attribute  Name 


liNEATTRIBirTES 


MARKER  ATTRIBUTES 


TEXT  attributes 


CHARACTER  ATTRIBUTES 

FILL  ATTRIBUTES 


EDGEATTRIBirrES 


PATTERN  ATTRIBirrES 

OUTPUT  CONTROL 

PICK  IDENTIFIER 
ALL  attributes 
ALL  ■ 


LINE  BUNDLE  INDEX 
LINE  TYPE 
LINE  WIDTH 
LINE  COLOUR 
LINE  CLIPPING  MODE 
MARKER  BUNDLE  INDEX 
MARKER 'TYPE 
MARKER  SIZE 
MARKER  COLOUR 
marker  CUPPINC  MODE 
TEXT  BUNDLE  INDEX 
TEXT  PONT  INMX 
TEXT  PRECISION 

character  EXPANSION  FACTOR 

character  spacing 

TEXT  COLOUR 
character  HEICHT 
CHARACTER  ORIENTATTON 
TEXT  PATH 
TEXTAUCNMENT 
RLL  BUNDLE  INDEX 
Ulterior  STYLE 
FILL  COLOUR 
HATCH  INDEX 
PATTERN  INDEX 
EDGE  BUNDLE  INDEX 
EDGE  TYPE 
EDGE  WIDTH 
EZXiE  COLOUR 
EDGEVBffllUTY 
EDGE  CUPPING  MODE 
FILL  REFERENCE  POINT 
PATTERN  SIZE 
AUXILIARY  COLOUR 
TRANSPARENCY 
PICK  IDENTIFIER 

Alt  auributes 

Ail  attnbuies  and  control  elemena 
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Table  XXXX  InhehcaiKc  Filler  Selection  Namet  for  Aspea  Source  Flags 


ASF  Group  Name 


Individual  ASF  Nanc 


UNEASFS 
MARKER  ASPS 
TEXTASFS 

RLL  ASFS 

EDGE  ASPS 

ALL  ASPS 


LINE  TYPE  ASF 

LINE  Wirmi  ASF 

LINE  COLOUR  ASF 

MARKER  TYPE  ASF 

MARKER  SIZE  ASF 

MARKER  COLOUR  ASF 

TEXT  FONT  INDEX  ASF 

TEXT  PRECISION  ASF 

CHARACTER  EXPANSION  FACTOR  ASF 

CHARACTER  SPACING  ASF 

TEXT  COLOUR  ASF 

INTERIOR  STYLE  ASF 

FILL  COLOUR  ASF 

HATCH  INDEX  ASF 

PATTERN  INDEX  ASF 

EDGE  TYPE  ASF 

EDGE  WIDTH  ASF 

EDGE  COLOUR  ASF 

All  aapect  source  flags 


An  example  of  ihe  COPY  SEGMENT  element  with  the  INHERITANCE  FILTER  element  is  as  follows; 


BEGIN  METAFILE 


BEGIN  SEGMENT  (1) 

LINE  COLOUR  (blue) 

POLYLINE  (blue  soUd  line) 

END  SEGMENT 

BEGIN  DEFAULTS  REPLACEMENT 
LINE  TYPE  (dash) 

END  DEFAULTS  REPLACEMENT 

BEGIN  SEGMENT  a) 

LINE  <X)LOUR  (red) 

INHHERTTANCE  FILTER  (UNE  ATTRIBUTES.STATE  USD 
COPY  SEGMENT  (1) 

POLYUNE 

INHERITANCE  FILTER  (LINE  ATTRIBUTES^ECMENT) 

COPY  SEGMENT  (1) 

POLYLINE 
END  SEGMENT 

BEGIN  PICTURE  *._* 

BEGIN  PICTURE  BODY 
LINE  COLOUR  (green) 

INHERITANCE  FILTER  (LINE  aTTRIBUTES^ECMEND 
COPY  SEGMENT  (2) 


POLYLINE 

INHERITANCE  FILTER  (LINE  ATTRIBUTES .STaTE.LISD 
COPY  SEGMENT  (2) 


BEGIN  SEGMENT,}) 


red  dashed  line 
raddaatwdlne 
blue  solid  line 
red  dashed  line 
peen  dashed  line 

green  dashed  line 
green  dashed  line 
green  dashed  line 
green  dashed  litre 


(red  dadred  line) 
(red  dashed  line) 

(bhie  solid  line) 
(red  dashed  line) 
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rad  dahod  Late 


LINE  COLOUR  (rad) 

COPY  SEGMENT  (I ) 

INHERITANCE  FILTER  (UNE  ATTRrBUTES.SECMENT; 

COPY  SEGMENT  (!)  biu*  soud  !«e 

END  SEGMENT 


LINE  COLOUR  (*reen) 

COPY  SEGMENT  (3)  rad  dah«d  l3»e 

blue  wild  !tnc 

INHERITANCE  FILTER  (UNE  ATTRJBITTES.STATE  LIST) 

COPY  SEGMENT  (3)  inran  duhed  !ne 

pvmduMdlKW 


END  PICTURE 
END  METAFILE 


Oippui|  IS  no*  included  in  ihe  CNHERITANCE  FILTER.  There  it  »  tcpvsie  eiemont  ih»i  coniroii  clippni  behaviour 
CUP  inheritance  Iu  values  may  be  eiiher  itaie.lisi  or  tracnociion 

II  Ib*  value  is  lUte.lisi'.  ih«  the  clip  ricun|le  associated  with  prtmiuves  m  the  copied  tcgmcni  n  that  of  die  'ast  CUP 
RECTANGLE  eaooumered  tn  the  meufile  element  sequence  pnor  to  the  COPY  5ECMEVT  eiement  dial  u  the  value  ir. 
the  'modal  suie  list'. 


II  the  value  is  'tnienecson .  and  J  both  the  modal  tiate  list  clip  mdiciior  of  the  sepnm  are  on .  then  the  intersection  of 
the  copied  segment  is  the  inieneeuoti  of  the  modal  luie  lai  recungle  »'d  the  pnirnuve  i  associated  clip  recisnjie.  If 
eithor  indicator  is  off.  then  there  is  no  conenbunon  from  lU  associsted  rectangle.  To  illuspaie;  if  TA  is  the  copy 
tmslonnadoic 

BEGIN  SEGMENT  A 
CUP  RECTANGLE  R I 
POLYLINE  PI 
END  SEGMENT 

CUP  INHERITANCE  TNTERSECTION' 

CUP  RECTANGLE  R2 
POLYLINE  P2 
COPY  SEGMENT  fA.TA) 

POLYLINE  P3 

P2  and  P3  ne  vansfujiiied  by  RL  PI  ts  oinsformod  by  R2  Icomhmed  wuHi  TA(R1).  This  may  be  an  8*jided  convex 
polygon,  if  TA  causes  rotation  and  skewing. 

This  composition  of  clipping  rociangles  continues,  however  many  levels  deep  the  segment  hierarchy  is  nested.  For 
eaampie: 

BEGIN  SEGMENT  A 
CUP  RECTANGLE  RO 
POLYLINE  PO 
CUP  RECTANGLE  Rl 
POLYLINE  PI 
END  SEGMENT 

BEGIN  SEGMENT  B 

CUP  RECTANGLE  R2 

CUP  INHERITANCE  "INTERSECnON  ' 

COPY  SEGMENT  (A.TA) 

END  SEGMENT 


CUP  RECTANGLE  R3 

CUP  INHERITANCE  ‘INTERSECnON- 
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COPY  SEGMENT  OB.TB) 

POLYLINE  P3 

The  efTecuve  clipping  'rectangles'  are: 

for  Pi;  TB(R2  intenecoon TA(Rl)}  inunection  R3 
for  P2:  TB(R2)  intenecoon  R3 
forP3:  R3 

for  PO:  TB(R2  intenection  TA(RO))  ratmocuon  R3 

Fnm  this  example  it  can  be  teen  that  the  effective  clipping  'rectangle*  can  in  fact  be  an  arbitrary  convex  polygon. 
Annex  D  contains  recommended  fallback  for  imerpreten  which  cannot  perform  such  clipping. 

Segment  Transformations  are  never  applied  to  clipping  boundaries.  The  default  value  for  CLIP  INHERITANCE  it 
itaiejist’. 


4.12.6  Save  and  Restore  Primitive  Cuiitcxt 


Two  elemenu  are  p^vidod  to  save  and  restore  a  context  that  is  attributes  and  control  elements.  This  capability  allows  a 
list  of  aimbutes  snd  connl  elemenu  to  be  stored  in  the  metafile  which  can  be  referenced  by  name  at  a  later  potni  m  the 
metafile.  This  cxpabiliiy  can  be  used  to  save  snd  restore  attributes  and  control  elen-  enu  in  conjunction  with  opening  and 
closing  segments. 

py,  details  and  table  in  here  for  the  save  and  restcre?****"** 


Peg* 4/ 

Add  the  following  text  after  the  state  diagram 

NOTE:  Many  elemenu  allowed  in  state  PO  can  also  occur  in  the  METAFILE  DEFAULTS  REPLACEMENT. 


152 


Page4l 


Add  the  following  uble  following  the  sute  diagnm 
Table  3.1:  CGM  Elements  by  their  allowed  states 


CGM 


Element 


CGM  Sutei 


PCS  MDS  DR  GSS  PDS  POS  TOS  LSS  FOS 


BEGIN  PICTURE _ 


BEGIN  HCTURE  BODY 


END  PICTURE 


BEGIN  SEGMENT 


END  SEGMENT 


END  METAFILE 


METARLE  VERSION  _ 


METARLE  DESCRIPTION _ 


VDCTYPE 


INTEGER  PRECISION 


REALPREaSION  _ 


INDEX  PRECISION  _ 


COLOUR  PRECISION 


COLOUR  INDEX  PRECISION 
NAME  PRECISION 


MAXTUMUM  COLOUR  INDEX 


COLOUR  value  extent 


METAFILE  ELEMENT  LIST 


METAFILE  DEFAULTS  REPL. 


FONTUST  _ 


CHARACTER  SET  LIST 


CHAR  CODING  ANNOUNCER 


metafile  CATEGORY  _ 


MAXIMUM  VDC  EXTENT 


SEGMENT  PRIORITY  EXTENT 


SCALING  MODE 


COLOUR  SELFCnON  MODE 


MARKER  SIZE  SPEC  MODE 


EDGE  WIDTH  SPEC  MODE 


VDCEXTENT  _ 


BACKGROUND  COLOUR 


DEVICE  VIEWPORT 


DEVICE  VIEWPORT  MAPPING 


EVICE  VPORT  SPEC  MODE 


LINE  REPRESENTATION 


marker  REPRESENTATION 


TEXT  REPRESENTATION 


FILL  REPRESENTATION 


EDGE  REPRESENTATION 


VDC  INTEGER  PREaSlON 
VDC  REAL  PRECISION 
AUXILIARY  COLOUR 
transparency 


CGM 


Bemem 


CGM  States 


PCS  MDS  Dk  GSS  PDS  POS  TOS  LSS  FOS 


CUP  RECTANGLE 


CUP  INDICATOR 


LINE  CUPPO.G  MODE 


MARKER  CUPPING  MODE 


EDGE  CUPPING  MODE 


BEGIN  FIGURE 


END  FIGURE 


NEWREQW 


IMPUCrr  EDGE  VISIBIUTY 


SAVEPRIMrnVEATTS 


RESTORE  PRIMITIVE  ATTS 


POLYLINE 


DISJOINT  POLYLINE 


POLYMARKER 


TEXT 


RESTRICTED  TEXT  _ 


APPEND  TEXT 


POLYGON 


POLYGON  SET  _ 


CELL  ARRAY 


GDP 


RECTANGLE 


CIRCLE 


QRCULAR  ARC  3  POINT 


CIRCULAR  ARC  3  FT  CLOSE 


QRCULAR  ARC  CENTRE 


QRCR  ARC  CENTRE  CLOSE 


ELLIPSE 


ELUrnCALARC 


ELUPnCAL  ARC  CLOSE 


QRC  ARC  CENTRE  REVO 


CONNECTING  EDGE 


LINE  BUNDLE  INDEX 


LINE  TYPE 


UNEWIOTH 


LINE  COLOUR 


MARKERS 


MARKERS 


MARKER  COLOUR 


TEXTBUNDLE  INDEX 


TEXT  PONT  INDEX 


TEXT  PRECISION 


CHAR  EXPANSION  FACTOR 


CHARACTER  SPAONG 


TEXT  COLOUR 


CHARACTER  HBGHT 


CHARACTER  ORIENTATION 


TEXT  PATH 

X 

X 

TEXTAUGNMENT 

X 

X 

CHARACTER  SET  INDEX 


ALT  CHAR  SET  INDEX 


FILL  BUNDLE  INDEX 


INTERIOR  STYLE 
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CGM 

COM 

States 

Element 

PCS 

MDS  DR 

GSS 

PDS 

POS 

TOS 

LSS 

FOS 

:: 

FILL  COLOUR 

X 

X 

X 

X 

HATCh  INDEX 

X 

X 

X 

X 

PATTERN  INDEX 

X 

X 

X 

X 

EDGE  BUNDLE  INDEX 

X 

X 

X 

X 

X 

EDGETYPE 

X 

X 

X 

X 

X 

EDGE  WIDTH 

X 

X 

X 

X 

X 

EDGE  COLOUR 

X 

X 

X 

X 

X 

EDGEVIsmETTY 

X 

X 

X 

X 

X 

FILL  REFERENCE  POINT 

X 

X 

X 

X 

PATTERN  TABLE 

X 

X 

X 

PATTERN  SIZE 

X 

X 

X 

X 

COLOUR  TABLE 

X 

X 

X 

ASPECT  SOURCE  FLAGS 

X 

X 

X 

X 

xai 

1  -  1 

IPICKIDENnnER 

X 

X 

X 

X 

1  1 

(ESCAPE 

X 

X 

X 

X 

X 

X 

X 

1  1 

MESSAGE 

X 

X 

X 

X 

X 

X 

X 

APPUCATION  DATA 

X 

X 

X 

X 

X 

X 

X 

1  1 

COPY  SEGMENT 

X 

X 

X 

INHERITANCE  FILTER 

X 

X 

X 

-X 

CUP  INHERITANCE 

X 

X 

X 

X 

!  1 

SECMEffT  TRANSFORMATION 

X 

X 

X 

SEGMENT  HIGHUGHTING 

X 

X 

X 

SEGMENT  DISPLAY  PRIORITY 

X 

X 

X 

SEGMENT  PICK  PRIORITY 

X 

X 

X 

1  1 

PIXEL  array 

X 

PCS  Picaac  Clos«d  Suic 

MDS  MeuHIc  Oescnpiion  Suie 

DR  Defaulu  Rq)lacemem  Mode 

CSS  Global  SegmciK  Suie 

PDS  Pictwe  Descnpuan  Suie 

POS  Picoire  Open  State 

TOS  Text  Open  (Paniai  text)  State 
LSS  Local  Segment  State 

FOS  Figwe  Open  State 

Notes: 

1:  BEGIN  METAFILE  is  the  only  eiemen  allowed  in  (he  state ‘Meuine  Gosed' 

2:  Only  Edge  ASFi  an  allowed  in  Figure  Open  State 

3:  Use  of  TEXT  PRECISION  in  text  open  state  is  pcnmoad,  however  the  intended  residt  is  not  well  defined  ant 

such  usage  is  likely  to  lead  to  unpredictable  resultt. 

4:  Defaults  replacement  mode  is  not  actually  a  metafile  suue.  but  is  included  in  this  table  for  completeness. 

Pagt42 


Sub-cUusc  3.1:  Add  the  following  after  the  ninth  paragraph  which  starts  with  the  sentence:  The  Exiemr 
Elements....": 

The  Segment  Elements  (see  3.10)  provide  for  the  groupuig  and  manipulation  of  elements. 
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Sub>€iause  5.1 :  Add  the  followini  at  the  end  of  the  table  of  abbreviations  of  data  type  names: 


N 

Name 

SN 

Segment 

N«ne 

VP 

Vewpon 

Point 

VC 

Viewport 

Cootdinale 

Ideniiiler  for  segmetus,  pick  "  a  set  of  values 

used  with  SAVE  and  RESTORE  PRIMITIVE  CONTEXT 

Realization  is  integer,  range  is  dependent  on  NAME  PRECISION 

Segment  Identifier 

Realizadon  is  an  inieger. 

Two  VSe  values  representing  the  a  and  y  coordinates  of  a  poim  in 

viewport  spedfication  space 

Single  real  or  integer  value  u  detomined  by  the 

DEVICE  VIEWPORT  SPECinCATION  MODE; 

R  (raetion  {0_1]  of  default  viewport 

I  millimetres  (scaled) 

I  native  device  units 


Pagt46 

Add  the  following  sub-clauses  after  sulxlause  5.2JS: 

5.2.6  BEGIN  SEGMENT 
Parameters: 

Segment  Identifier  (N) 

Description: 

This  element  demarcates  the  start  of  a  segment.  All  subsequent  elements  until  the  neat  END  SEGMENT  will 
belong  to  this  segnenL 

Reference: 

4.2 

4.12J 


5.2.7  END  SEGMENT 
Parameters: 

Now 

Description: 

Subsequent  elements  win  no  longer  belong  to  a  segmenL 

Reference: 

4.2 
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Add  the  following  at  the  end  of  the  Description  section  of  sub-clause  5  J.l 
The  CGM  as  defined  in  ISO  8632/1- 1987/Add.  1  is  version  two  (2). 
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-  Sub-clause  5  J.l  1:  Add  the  following  shorthand  names  at  the  end  of  the  list  given  in  the  second  psragra^  of 
the  Description': 

VER.l-STA-nC-ALLSET 
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EXTENDED-PRIMITIVES  SET 
VER  J-STATIC-GKSM  SET 


Page55 

Add  the  following  sub-cUuses  after  nib-ciatue  5  J.IS; 

5.3.16  NAME  PREOSION 
Parameters: 

The  foim  of  the  paramter  depends  on  the  specific  encoding. 

Description: 

The  precisian  for  operands  of  data  type  name  (N)  is  specified  for  subsequent  data  of  type  N.  The  precision  is 
defined  as  the  field  width  measured  in  ladts  applicable  to  the  specsfic  encoding. 

Reference: 

O 

SJ.17  MAXIMUM  VDC  EXTENT 

Parameters: 

fintcomer  (P) 

secceideotner  (P) 

Description: 

The  two  comcn  define  a  rectangular  extent  in  VDC  space  which  bounds  ihe  values  of  the  VDC  EXTENT 
elements  which  may  be  found  in  the  metafile.  It  may  be.  but  need  not  be.  a  closest  bound  in  the  seme  that  it 
exactly  equals  the  un^  of  the  extern  raeiangles  in  the  metafile. 

Reference: 

4AA 


5JAS  SEGMENT  PRIORITY  EXTENT 

Parameters; 

minimum  extent  (1) 
maximuin  extent  (I) 

Description: 

The  patamcteis  represent  an  extent  which  bounds  the  segment  display  and  pick  priority  values  which  will  be 
encountered  in  the  metafile.  It  need  not  represent  the  exact  priorities  in  the  metafile.  The  lowest  display 
priority  is  zero. 

References: 

4.12.43 

4.12.4.4 


Page  56 

Add  the  following  note  to  the  aid  of  sub.cieuse  S.4. 1  (SCALING  MODE) 

NOTE:  If  both  device  viewport  and  scaling  mode  appear  in  the  same  maaflle  then  the  last  specified  is  used.  I  f  neither 
appear  then  the  default  vaiuei  for  device  viewpon  take  precedence. 
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Add  the  following  sub-clauses  after  sub<lause  5.4.7: 

S.4.S  DEVICE  VIEWPORT 

Parameters: 

fint  corner  (VP) 

second  coiner  (VP) 

Description: 

The  two  parameters  define  the  opposite  comers  of  a  rectangular  viewport  on  the  device's  drawing  surface. 
These  parameters  are  specified  by  the  unit  system  selected  by  OE'VICE  VIEWPORT  SPECFICATION 
MODE 

The  effective  viewport  is  that  area  of  the  drawing  surface  onto  which  the  VDC  extent  rectangle  is  mapped.  If 
the  cusrent  DEVICE  VIEWPORT  MAPPING  forces  isotropic  mapping,  and  the  aspect  ratio  is  not  equal  to 
that  of  the  device  viewport,  the  effective  viewport  will  be  smaller  than  the  specified  viewport  on  one  or  die 
other  axis  (but  not  both). 

If  the  current  DEVICE  VIEWPORT  MAPPING  does  not  force  isotropic  mapping,  the  effective  viewport  will 
be  the  same  as  the  specified  viewport.  If  the  Device  Viewpon  exceeds  the  available  drawing  surface,  the 
Device  Viewport  is  still  used  to  determine  the  VDC-to-Device  mapping. 

Mirroring  or  180  degree  roution  of  the  image  may  be  achieved  by  specifying  the  comers  in  some  way  other 
than  that  the  first  is  beiow  md  to  the  left  of  the  second. 

NOTE  If  both  device  viewport  and  scaling  mode  appear  in  the  same  metafile  then  the  last  specified  is  used.  If  neither 
appear  then  the  default  values  for  device  viewpon  take  precedence  where  these  are  allowed  in  the  same  category. 

Reference: 

4.4.7 


S.4.9  DEVICE  VIEWPORT  SPECinCATION  MODE 
Parameters: 

VC  specifier  (one  of:  firacnon  of  drawing  surface 

millimetres  with  scaiefactor. 
physical  device  uniaXE) 

Metric  scale  factor  (R) 

Description 

This  element  determines  how  subsequent  eiemenu  using  the  data  type  VC  (Viewpon  Coordinate)  or  VP 
(Viewpon  Poim)  wiU  be  definedL 

Thcac  parameters  mey  be  specified  in  one  of  tine  modes:  haciion  of  drawing  surface;  millimetres  with  scale 
facter,  or  physical  device  tmia. 

When  the  VC  spnfiar  is  'fraction  of  drawing  surface '.  the  value  (0.0. 0.0)  cenesponds  to  the  lower  left  comer 
and  the  value  (LCC  ID)  coneepondi  to  the  upper  lighi  eonar  of  the  default  device  viewport.  (The  default  device 
viewpon  is  the  largest  unrotaiad  racangular  arte  viuble  on  the  drawing  surface.)  Numbers  ouuidc  of  the  range 
[0.0_1.0]  nuy  be  specified  (see  OEVin  VIEWPORT),  la  this  case  the  metric  s^e  factor  is  ignored. 

When  the  VC  speeifier  is  'milliiacms  with  scaleftctor'.  the  tnenic  scale  factor  parameter  represents  the  distance 
(in  millimetres)  on  the  drawing  surface  corresponding  m  oiw  unit  in  VP  space.  One  unit  in  VP  space 
represenis  one  millimem  multiplied  by  the  metric  scale  faetor.  The  value  (0.0)  coiresponds  to  the  tower  left 
comer  and  the  vahiea  increase  positively  to  the  right  and  upwards. 

When  the  VSC  specifier  is  'physical  device  units',  the  native  unttt  and  handedness  of  the  physical  device  are 
used.  In  this  case  the  metric  scale  factor  is  ignored. 
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Metric  scaling  with  a  scale  facuir  provkles  a  device-independent  means  of  generating  output  at  a  known  scale 
factor.  In  metric  mode,  a  scale  factor  of  1.0  indicates  that  the  VC  are  in  units  of  millimetres:  a  scale  factor  of 
0.0254  would  imply  a  VSC  of  one  thousand  per  inch.  The  only  allowed  data  type  for  physical  device  units  is 
iniegcr. 

RcfcrcDcc: 

4.4.7 

5.4.10  DEVICE  VIEWPORT  MAPPING 
Parameters: 

Isotropy  flag  (one  of:  not  fotced.  forcadXE) 

Horizontal  alignment  flag  (one  of:  LeA.  Centre.  RightXE) 

Vertical  alignment  flag  (one  of:  Bottom,  Centre,  TopXE). 

Dcscriptloii: 

This  element  determines  how  the  coordinate  mapping  is  derived  from  the  VDC  EXTENT  and  the  specified 
DEVICE  VIEWPORT.  The  remaining  parameters  are  only  significant  if  isotropy  is  forced  by  the  first 
parameter.  If  so,  the  effective  viewpon  is  generally  smaller  tlm  the  specified  viewport,  and  these  parameters 
deieimine  how  it  will  be  positioned  within  the  specified  vienvporL  "LeA'  and  'bottom’  are  interpret^  as  being 
towards  the  'first  comer’  the  specified  DEVICE  VIEWPORT,  regardless  of  any  mirroring  or  rotation  of  the 
viewpoR  on  the  physical  device. 

Reference: 

4.4.7 

5.4.11  LINE  REPRESENTATION 

Pnmetets 

line  bundle  index  (DC) 
line  type  indicaior  (DC) 
line  width  specifier 

if  line  width  specification  mode  is  ‘absolute’, 
absolute  line  width  (VDC) 

if  liiK  width  spcificaiion  mode  is  ’scaled', 
line  width  scale  factor  (R) 

line  colour 

if  the  colov  selection  mode  is  indexed', 
line  colour  index  (Cl) 

if  the  colour  selection  mode  is  ‘direct’, 
line  colour  value  (CO) 

Description: 

In  the  line  bundle  table,  the  given  Una  bimdle  index  is  associated  with  the  specific  parameters. 

Line  type  is  specified  «d  behaves  as  indicated  in  the  LINE  TYPE  attribute  element 

Line  width  is  defined  in  the  cument  UNE  WIDTH  SPECIFICATION  MODE  and  is  stored  in  the  bimdle  table 
along  with  that  mode.  Thus  the  definiiion  is  immune  to  subsoquem  changes  in  tha  specification  mode. 

Line  coloio’  is  defined  in  the  current  COLOUR  SELECTION  MODE  and  is  stored  in  the  bundle  ubie  along 
with  that  mode.  Thus  the  definition  is  immune  to  subsequem  changes  to  the  selection  mode. 

Which  aspeca  are  used  depends  on  the  coiresponding  ASFs.  see  the  ASPECT  SOURCE  FLAG  element 

Refcrtncc: 

.  4  .4  8 

s.4.12  marker  representation 
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Parimctcni: 


marker  bundle  indn  (DO 
marker  type  indicaior  (DO 
marker  size  speeiCer 

L  iiiarkcr  size  speciltcatton  mode  is  ’absolute', 
absolute  marker  size  (VDC) 

if  marker  size  speciflcation  mode  is 'scaled', 
msker  size  scale  factor  (R) 

marker  colow 

if  the  cokmr  selection  mode  is  'indeaed'. 
marker  colour  index  (Cl) 

if  the  colour  selection  mode  is  'direct', 
marker  colour  value  (CD) 


Description: 

la  the  marker  bundle  table,  the  given  marker  buttdle  index  is  associated  with  the  specified  parameters. 

Marker  type  is  specified  and  behaves  as  indicated  in  the  MARKER  TYPE  attribute  element. 

Marker  ””  is  defined  in  the  current  MARKER  SIZE  SPECIFICATION  MODE  and  is  stored  in  the  bundle 
table  along  with  that  mode.  Thus  the  definitian  is  immune  u>  subsequem  changes  in  the  specification  mode. 

Marker  oolow  is  defined  in  (he  current  COLOUR  SELECTION  MODE,  and  is  stored  in  the  bundle  uble 
along  with  that  mode.  Thus  the  definition  is  immune  to  subsequent  changes  to  the  selection  mode. 

Which  aspects  are  used  depends  on  the  corresponding  ASPs,  see  the  ASPECT  SOURCE  FLAG  element 

Reference: 

S.4.13  TEXT  REPRESENTA'nON 
Parameters: 

text  biBidle  index  (DO 
text  fom  index  (DO 

text  precisian  (one  of:  soring,  character,  stroke)  (E) 
character  spacing  (R) 
character  expansion  factor  (R) 
text  colour 

if  iha  coloar  selection  mode  is  'indexed’, 
text  coknr  index  (O) 

if  the  colour  sdection  mode  is  'direct', 
text  colour  value  (CD) 


Description: 

In  tha  text  bundle  table,  the  given  uxt  bundle  index  is  asaociaied  with  the  specified  parameters. 

Text  font  index  is  specified  and  behevci  as  indicaiad  in  the  TEXT  FONT  INDEX  atiribuus  element 

Text  precisian  is  specified  and  behaves  as  indicstad  in  the  TEXT  DECISION  aitribuie  element 

Character  spacing  is  specifted  and  behaves  as  indicated  in  the  CHARACTER  SPACING  attribute  element 

.  Character  expansion  factor  is  specified  and  behaves  as  indicated  in  the  CHARACTER  EXPANSION  FACTTOR 
attribute  element 
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Tmi  colour  is  defined  in  the  current  COLOUR  SELECTION  MODE,  and  is  stored  in  the  bmdle  table  along 
with  that  mode.  Thus,  the  deftnidon  is  immune  to  subsequent  changes  to  the  selection  mode. 

Which  aspects  are  used  depends  on  the  corresponding  ASFs.  see  the  ASPECT  SOURCE  FLAG  eiemenL 

Rcrercnce: 

4.4.8 

5.4.14  nLL  REPRESENTATION 
Parameters: 

&Q  area  bundle  index  (DC) 

inierior  style  (one  of:  hollow,  solid.  paaemJtaich.  empty )(E) 

GU  colour 

if  the  colow  selection  mode  is  ‘indexed*, 
fill  colour  index  (Cl) 

if  the  colour  selecuon  mode  is  direct’, 
fill  colour  value  (CD) 

hatch  index  (DC) 
patton  index  (DC) 

Description: 

In  the  fin  bundle  table,  the  given  fill  bundle  index  is  associated  with  the  specified  parameters. 

Inierior  style  is  specified  and  behaves  as  indicated  in  the  INTERIOR  STYLE  auribuce  element. 

Fill  colour  is  defined  in  the  current  COLOUR  SELECTION  MODE,  md  is  stored  in  the  bundle  table  along 
with  that  mode.  Thus,  the  definition  is  immune  to  subsequent  changes  io  the  selection  mode. 

Hatch  index  indicator  is  specified  and  behaves  as  ind.  ed  in  the  HATCH  INDEX  attribute  element. 

Panem  index  indicaior  is  specified  and  behaves  as  indicated  in  the  PATTERN  INDEX  attribute  element. 

Which  aspecu  are  used  depends  on  the  corresponding  ASFs.  see  the  ASPECT  SOURCE  FLAG  element. 

Reference: 

4.4.8 

5.4.15  EDGE  REPRESENTATION 
Pararacicrs: 


sdgebwidle  index  (DO 
edge  type  indicaair  (DC) 
edge  width  specifier 

if  edge  width  specification  mode  is  'absolute', 
absolute  edge  width  (VDQ 

if  edge  width  spcificaiion  mode  is  scaled', 
edge  width  scale  factor  (R) 

edgecokw 

if  the  colour  selection  mode  is  ‘indexed', 
edge  colour  index  (Q) 

if  the  colour  selection  nHide  is  'direct', 
edge  colour  value  (CD) 


Description: 

In  the  edge  bundle  ubie.  the  given  edge  bundle  index  is  associated  with  the  spccini.-d  parameters. 
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Edge  type  is  specified  ind  behaves  u  indicated  in  the  EDGETYPE  attribute  element. 

Edge  width  is  defined  in  the  current  EDGE  ■VWTH  SPEOHCATION  MODE  and  is  stored  in  the  bundle  table 
along  with  that  mode.  This  the  defnuiian  is  immune  to  subsetpiou  changes  in  the  spedficaiion  mode. 

Ed--  colour  is  thfined  in  the  currem  COLOUR  SELECTION  MODE  and  is  -trsd  in  the  bundle  uble  along 
with  that  mode.  Thus,  the  definiuon  is  immune  to  sutaMt]ucnt  changes  to  the  selection  mode. 

Which  aspects  are  used  depends  on  the  corresponding  ASPs,  see  the  ASPECT  SOURCE  FLAG  element 

Reference: 

4.4.8 
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Add  the  following  sub-clauses  after  sub^lause  53.6 

53.7  LI.NE  CLIPPING  MODE 
Parameters 

mode  (one  of:  locus,  shape.  locus  then  shape)  (E) 

Description 

The  Line  Cipping  Mode  is  set  to  the  value  specified. 

Reference: 

43.2 

53.8  MARKER  CLIPPING  MODE 
Parameters 

mode  (one  of:  locus,  shape,  locus  then  shape)  (E) 

Description 

The  Marker  Clipping  Mode  is  set  to  the  value  specified. 

Reference: 

43.2 

53.9  EDGE  CLIPPING  MODE 
Parameters 

mode  (one  of:  locus,  shape,  locus  then  shape)  (E) 

Description 

The  Edge  Clipping  Mode  is  set  to  the  value  specified. 

Reference: 

43.2 

S.S.I0  BEGIN  FIGURE 

Parameters: 

none 

Description; 

IS  the  fust  element  of  a  closed  figure.  All  subsequent  elements  until  the  next  END  RGURE  will  be  oan 
of  the  closed  figure.  ^ 

Reference: 

46.3 
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5^.11  END  nCURE 


PariRictcrs: 


« 

D<sc  ‘ptioa: 

This  dement  terminaies  (he  current  closed  Hgure. 

If  the  current  region  has  not  yet  been  closed  by  a  preceding  NEW  REGION  or  CONNECTINC  EDGE  element, 
and  the  last  point  of  the  last  line  element  is  not  coincident  with  the  current  closure  point  then  the  current 
subregion  is  closed  by  a  line  segment  connecting  the  last  point  of  the  preceding  line  element  to  the  ctureni 
closure  point  Tltis  line  becomes  a  part  of  the  boundary  spedficatioft  If  the  region  which  has  been  previously 
closed  is  empty,  or  the  last  point  of  the  last  line  element  is  coincident  with  the  current  closure  point  then  no 
line  segmetu  is  generated  by  this  elemem. 

Reference: 

4.6.8 


SJ.12  NEW  REGION 


Parameters: 

none 


Description: 

This  element  is  used  for  control  of  subregion  coistruction  within  closed  figures. 

If  the  current  region  has  not  yet  been  closed  by  a  preceding  NEW  REGION  or  CONNECTING  EDGE  element 
and  the  last  point  of  the  last  line  element  is  not  coincidou  with  the  current  closure  point  then  the  current 
subregion  is  closed  by  a  line  segment  cotmecting  the  last  point  of  the  preceding  line  element  to  the  current 
closure  point  This  Uric  becomes  a  part  of  the  boundary  specilkation.  If  the  region  which  has  been  previously 
closed  is  empty,  or  the  last  point  of  the  last  line  element  is  coincident  with  the  current  closure  point  then  no 
line  segment  is  generated  by  this  elemem. 

The  first  point  of  the  nest  line  elemem  following  a  NEW  REGION  element  becomes  the  new  closure  point 
starting  a  new  subregiott 

Reference: 

4.6.8 


5J.13  SAVE  PRIMITIVE  CONTEXT 


Parameters: 

Contest  name  (N) 

Description: 

This  elemem  allows  for  the  grouping  and  identification  of  the  set  of  current  values  of  the  attribute  and  control 
demenu  listed  in  the  list  below  as  a  single  named  entity. 

Groups  of  elements  may  ba  saved  in  a  picture  or  segment  using  the  context  name. 

The  anribuai  and  control  elements  which  nwy  be  saved  by  SAVE  PRIMITIVE  CONTEXT  and  restored  by 
RESTORE  PRIMTITVE  CONTEXT  are; 

••••REORDER  TABLE  •••••••••••••••••••••••••••• 

CHARACTER  CODING  ANNOUNCER 
AUXILIARY  COLOUR  (Note  1 ) 

EDGEBUNDLE  INDEX 
•  CLIP  RECTANGLE  (Note  3) 

EDGE  TYPE 
CLIP  INDICATOR 
EDGEWroTH(Note2) 
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TRANSPARENCY 
EDGE  CX>LOUR  {Note  1) 

UNE  BUNDLE  INDEX 
EDGE  VISIBILITY 
LINE  TYPE 

EDGE  CUPPING  MODE 
LINE  WIDTH  (Nous  2) 

LINE  COLOUR  (Note  1) 

UNE  CLIPPING  MODE 
CHARACTER  SET  INDEX 
MARKER  BUNDLE  INDEX 
CHARACTER  EXPANSION  FACTOR 
IbtAPlfPB  TVPP 

CHARACTER  CODING  ANNOUNCER 
MARKER  SIZE  (Note  2) 

CHARACTER  SPAQNG 
MARKER  COLOUR  (Note  1) 
CHARACTER  HEIGHT 
MARKER  CLIPPING  MODE 
CHARACTER  ORIENTATION 
FILL  BUNDLE  INDEX 
ALTERNATE  CHARACTER  SET  INDEX 
FILL  COLOUR  (Note  I) 

TEXT  BUNDLE  INDEX 

TEXT  FONT  INDEX 

FILL  REFERENCE  POINT  (Note  3) 

TEXTPRE(3SI0N 

INTERIOR  STYLE 

TEXT  COLOUR  (Motel) 

HATCH  INDEX 

tdctpath 

TEXTAUGNMENT 
PATTERN  INDEX 
PICK  IDENTIFIER 
PATTERN  SIZE 
ASPECT  SOURCE  FLAGS 


NOTES; 


1:  The  COLOUR  SELECTION  MODE  in  which  this  value  was  last  set  is  also  recorded. 

2:  The  corresponding  speaficauon  mode  in  which  this  value  was  last  set  is  also  recorded. 

3.  The  VDC  TYPE  in  efTeci  when  these  values  are  saved  is  also  recorded 

Reference: 

4.1L6 

SJ.14  RESTORE  PRIMITIVE  CONTEXT 

Parameters: 

Context  tune  (N) 

Description:  _ 

The  attribute  and  control  set  recorded  in  the  metafile  with  the  last  SAVE  PRIMITIVE  CONTEXT  element  ate 
recalled  on  intetpretation. 

Rercrence; 

4.12.6 
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Add  ’Jm  foUfiwnf  text  u>  (he  end  of  the  iccond  para^tph  of  fub<lnue  S.6J 
These  inurucuons  for  the  aentai  dupUyed  postuon  of  a  ftuxk<  only  apply  to  MARtC£K  CLIPPING  MODE  'oo-s 


Pagers 

Add  the  following  sub~ciauae  after  sub-clauae  5.6.  t9 
S.6J0  CIRCULAR  ARC  CXNTRE  REVERSED 
Parameters: 

ccTitrepoint  fP) 

DX.jurt.  DY.Jiart.  DX.end.  DY.end  (4VDO 
radius  (VOC) 

Description: 

A  ctreular  arc  is  drawn  which  is  deTined  as  follows; 

DX .start  and  DY.surt  derma  a  start  vector,  and  DX.catd  and  DY.end  dePme  an  end  vector.  The  uils  of  Jicse 
vecion  are  placed  on  ihe  eengepomt.  A  sun  ray  and  end  ray  are  denved  from  the  sun  and  end  veciors  The 
sun  and  end  rays  arc  semi-inrmuc  lines  from  the  centrepomi  in  the  directioru  of  die  sun  and  end  vectors 
respectively. 

The  specified  radius  and  -mtrepomt  define  a  circle.  The  «t  is  drawn  m  the  negative  angular  direction  ^as 
defined  by  VQC  EXTENT)  from  the  intenecuon  of  the  circle  and  the  sun  rsy  (a*  obuined  by  meaiurirg  i 
distance  'radius'  along  the  stan  ray  from  the  ctnarepoou)  to  the  imersecoon  of  the  circle  and  the  end  ray 

The  arc  is  displayed  with  cwrent  line  element  aonbutea. 

Valid  values  of  the  vector  oomponenis  are  those  which  produce  vectors  of  non-zero  length. 

Valid  values  of  radius  are  non-negative  VDC. 

If  the  start  ray  and  aid  ray  arc  coirxident.  it  u  ambiguous  whether  the  defined  arc  subtends  0  degrees  or  }60 
degrees  of  central  angle  (see  the  spectflcaiions  for  the  CIRCULAR  ARC  CENTRE  m  annex  Di. 

Reference: 

4  6 

S.6.:i  CONNECTI.NC  EDGE 

Parameters: 

none 

Description: 

During  the  construction  of  a  closed  figure  a  line  segment  connecung  the  last  pomi  of  the  preceeding  hne 
element  and  the  next  potra  is  added  to  the  boundary  definition.  The  next  poini.  which  must  be  differeni  from 
the  last  point,  mey  be: 

1 .  the  fast  point  of  the  neat  line  element,  or 

2.  the  current  closure  point,  that  is  in  cases  where  COT'TNECnNG  EDGE  is  followed  by  either  SEW 
REGION  or  END  FIGURE. 

The  appearsnee  of  the  connecung  edge  is  fully  determined  by  ihe  edge  itcnbuies  and  EDGE  VISIBILITY 


References; 

......... jjjj. 
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PaggSS 


Add  the  followint  subKdiUMS  afiei  lutxUusc  S.7J35 
S.7J6  PICK  IDENTIFIER 

PsraiBcttrs: 

pick  idenafier  CN) 

Oescrlptloo: 

The  pick  idenuHer  value  is  associated  with  all  of  the  graphical  primitive  dements  of  a  sesmer  unul  the  next 
PICK  IDENTIFIER  etemeai.  Usa|e  of  the  PICK  IDENTIFIER  cn  interpreuiion  is  dependent  upon  the 
sppiicaoon  aid  on  the  caUi(ory  of  the  mcunic. 

Reference: 

4.79 


Page  100 

Add  the  following  sub-clause  after  sub-clause  5.9; 

S.IO  Segment  elements 

5.10.1  Segment  control  elements 

5.10.1.1  COPY  SEGMENT 

Parameters: 

segm  Bit  identifier 
copy  tramfoimaxion  mairis: 

scaling  and  toudon  portion 
nansiation  portian 
segment  transfonnauon  application 

Description: 

The  segment  which  is  indicsieid  by  the  segmeu  identifier  is  referenced  at  th<>  psitu  in  the  meufile  for  copying 
into  the  picture,  or  into  s  segmem  when  referenced  ftom  a  segmem.  on  interpretation.  With  the  eaception  of 
the  segment  transforsnasan  aasofiated  with  the  oopied  segment,  the  identified  segment  is  referred  to  as  the 
copied  segment  The  segment  aioibutes  of  the  copied  segmem  are  ignored.  Whether  or  not  this  segment  is 
ignored  is  controlled  by  the  'segmem  transformation  application'  parameter.  The  segment  aitribuies  of  the 
segment  in  which  the  COPY  SEGMENT  may  occur  aic  unchanged  by  this  element 

The  copy  oansfortnadon  is  applied  to  aO  primiiivc  elements  of  the  copied  segmem  before  they  are  copied  into 
the  open  segment  The  copy  aaRaformation  is  also  ^jplied  to  dipping  rectan^es  oader  some  cucumstsnees. 

The  INHERITANCE  FILTER  eicmem  allows  for  control  of  the  atihbute  values  which  are  used  when  copying 
segments.  Tliis  filler  controls  whether  individual  ashbuie  values  an  reapplied  to  the  graphical  primitives.  The 
effecu  of  INHERITANCE  FILTER  are  described  in  Qause  4.  The  way  in  which  clipping  is  applied  to 
primitives  within  a  copied  segmem  is  comrelled  by  CLIP  INHERITANCE  (tee  Clause  4). 

The  'segmem  cransformatien  application*  parameter  controb  whether  or  not  the  segment  transformation 
associated  with  the  copied  segmem  will  be  a^ied  as  at  elTect  of  the  copy  process.  If  it  is,  the  applicauon  of 
the  segmem  transformation  is  never  applied  to  a  clip  rectangle  associated  with  a  copied  object 

Reference; 

4  12.1 
4.12.5 

5.10.1.2  INHERIT A.NCE  RLTER 
Parameters: 

Tihcr  jelecuon  lunbute  designator  (list  elemenu  or  groups  from: 


(SN> 

(2*2xR) 

OsUVDO 

(one  of:  NO.  YES)  (E) 


166 


LINE  BUNDLE 
LINE  TYPE 
UNEWHTTH 
LINE  COLOUR 
LINE  CLIPPING  MODE 
MARKER  BUNDLE  INDEX 
MARKER  TYPE 
MARKER  SIZE 
MARKER  COLOUR 
MARKER  CLIPPING  MODE 
TEXT  BUNDLE  INDEX 
TEXT  PONT  INDEX 
TEXT  PRECISION 

CHARACTER  EXPANSION  FACTOR 

CHARACTER  SPAONG 

TEXT  COLOUR 

CHARACTER  HECHT 

CHARACTER  ORIENTATION 

TEXT  PATH 

TEXTAUGNMENT 

FILL  BUNDLE  INDEX 

INTERIOR  STYLE 

FILL  COLOUR 

HATCH  INDEX 

PATTERN  INDEX 

EDGE  BUNDLE  INDEX 

EDGETYra 

EDGE  width 

EDGE  COLOUR 

EDGEVISmiUrY 

EDGE  CUPPING  MODE 

FILL  REFERENCE  POnrr 

PATTERN  SIZE 

AUXILIARY  COLOUR 

TRANSPARENCY 

LINE  ATTRIBUTES 

MARKER  ATTRIBUTES 

TEXT  ATTRlBirrES 

CHARACTER  ATTRIBUTES 

FILL  ATTRIBUTES 

EDGE  ATTRIBUTES 

PATTERN  ..ITRIBUTES 

OUTPUT  COtGROL 

PICK  IDENTIFIER 

ALL  ATTRIBUTES 

ALL 

LINE  TYPE  ASF 

UNE  WIDTH  ASF 

LINE  COLOUR  ASF 

MARKER  TYPE  ASF 

MARKER  SIZE  ASF 

MARKER  COLOUR  ASF 

TEXT  FONT  INDEX  ASF 

TEXT  PRECISION  ASF 

CHARACTER  EXPANSION  FACTOR  ASF 

CHARACTER  SPACING  ASF 

TEXT  COLOUR  ASF 

INTERIOR  STYLE  ASF 

FILL  COLOUR  ASF 

HATCH  INDEX  ASF 

PATTERN  INDEX  aSF 

EDGE  TYPE  ASF 

EDGE  WIDTH  ASF 

EDGE  COLOUR  ASF 


UNEASF5 
MAiUCERASFS 
TEXTASFS 
FILL  ASFS 
EDGE  ASFS 
ALL  ASFS 


Dcscriptioa: 

The  setting  of  the  inhaiunee  filler  is  modified  for  those  ssribuies  in  the  niter  selection  list.  According  to  the 
setting,  attributes  are  inhcriied  fiom  the  current  state  lisa  or  from  the  copied  segmenL 


Reference: 

4.12J 


S.10.1.J  CUP  INHERITANCE 

Parameters: 

clip  inheritance  (one  of:  state  list,  intersection) 

Dcscriptioa: 

The  behaviour  of  clipping  u  applied  to  primitives  in  copied  segmenu  is  defined.  Simple  clipping  against  the 
current  rectangle  in  the  modal  state  list  is  selected  by  the  value  'siaie.list'.  The  value  imerseetton'  not  only 
selecu  the  clip  rectangle  to  come  from  the  segment  but  also  enables  an  'object  clipping'  feature.  The 
transformation  of  clip  rectangles  and  accumulation  or  composition  of  multiple  oransformed  rectangles  is 
enabled,  depending  upon  the  settings  of  CLIP  INDICATOR.  See  Cliuse  4  for  i  descripuon  of  the  mechanism. 

References: 

4.1L1 

4.12J 


5.10.2  Segment  Attribute  Elcmcnu 

Segment  Attribute  Elements,  if  used,  shall  all  appear  immediately  after  BEGIN  SEGMENT,  before  the  first  element  of 
another  type.  The  segment  idenoTter  shell  refer  to  the  segment  in  which  the  elemenu  are  contained. 


S.10.2.1  SEGMENT  TRANSFORMATION 
Parameters: 


segment  idenofier  (N) 
transfotmaiion  matrix: 

scaling  and  roution  portion  (2x2xR) 

translation  portion  (2x  1  x  VDC) 


Description: 

The  segmou  trarafotnuiion  maoix  for  the  identified  segmem  is  set  to  the  specified  parameter. 
Tlte  default  segment  transfotmanon  is  the  identity  matrix. 

Reference: 

4.I2.4J 

5.10.2.2  SEGMENT  HIGHLIGHTING 


Parimcttrs: 

segment  idenufier  (N) 

highlighting  (one  of:  normsL  highlighted)  (E) 

Description: 

The  segment  highlightiing  for  the  identified  segment  is  set  to  the  specified  vtlue.  When  the  highlighting 
attribute  is  set  to  highlighted',  the  visual  appearaiKe  of  the  segment  is  interpretauon  dependent.  When  the 
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highlightinf  aaiibute  ti  set  lo  'norm«l‘.  ttie  segment  is  displayed  according  lo  the  segment  and  pivniiive 
asnbutea. 

RcfcrcBCc: 

4.12.4.2 

S.IO^  SEGMENT  DISPLAY  PRIORITY 
Parameters: 

segment  idenalier  (ft) 

segment  display  priority  d) 

Description: 

Tlie  segment  display  priority  for  the  identified  segment  is  set  to  the  specified  value. 

Segments  with  higher  segment  display  priority  appear  to  be  in  front  of  segments  with  lower  segment  dispiav 
priorities.  When  the  segment  display  priorities  of  two  overlapping  segments  are  the  same,  the  order  in  whicj. 
they  appear  is  interpretation  dependent 

Reference: 

4.12.4.3 

5.10.2.4  SEGMENT  PICK  PRIORITY 
Parameters: 

segment  idendfier  (N) 

segment  pick  priority  (I) 

OcscripcioB: 

The  segment  pick  priority  for  the  identified  segment  is  set  to  the  speciHed  value.  The  pick  priority  does  not 
affect  the  display  of  segments. 

Reference*. 

4.114.4 


Pagt  103 

Cause  6:  Add  the  following  at  the  end  of  clause  6: 


NAME  PREQSION 

enaxiing  dependent 

MAXIMUM  VDC  EXTENT 

VDC  EXTENT 

SEGMENT  PRIORITY  EXTENT 

0...255 

DEVICE  VIEWPORT 

0..1..0..1. 

DEVICE  VIEWPORT  SPEOFICAnON  MODE 

fraction  of  thawing  surface 

DEVICE  VIEWPORT  MAPPING 

farcedJeft.boiiom 

UNE  REPRESENTATION 

ntopraer  d^esslent 

MAF.KER  REPRESENTATION 

mapmer  dependent 

TEXT  REPRESENTATION 

mtoptesBr  diperieu 

FILL  REPRESENTATION 

iraerpmer  dependent 

EDGE  REPRESENTATION 

imapmer  dependent 

LINE  CUPPING  MODE 

locus 

MARKER  CLIPPING  MODE 

locus 
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EDGE  CLIPPING  MODE 

locus 

PICK  IDENTIFIER 

0 

INHERITANCE  FILTER 

segmem 

CUP  INHERITANCE 

state  list 

SBjMENT  TRANSFORMATION 

1.0  0.1 

SEGMENT  HIGHUGHTING 

noimal 

SEGMENT  DISPLAY  PRIORITY 

0 

SEGMENT  PICK  PRIORITY 

0 

Page  104 

Add  the  following  clause  after  sulxlause  7.4 

Conformance  for  Version  2  metafiles 


This  confonnance  section  defines  conformance  for  metafiles  which  ue  'version  2'.  A  Computer  Graphics  Metafile 
(CGM)  is  said  to  confonn  to  the  standard  if  it  implements  precisely  all  the  elements  required  for  a  version  2  metafile  as 
ctefined  in  this  sustdard.  When  determining  conformance  of  a  CGM.  the  formal  grammar  shall  take  precedence. 


Pag€]23 


Add  the  following  to  the  end  of  sutxlause  O.h 

In  a  static  picture-captm  metafile  potcruially  dynamic  effects  are  avoided  by  limning  the  position  of  elements  with  such 
poiesuiaUy  dynamic  effects.  Thus  bundle  table  definitions  may  only  sppev  in  the  picture  descriptor.  In  s  metafile  the 
effecu  of  COLOUR  TABLE  and  PATTERN  TABLE  arc  unspecified  when  they  occur  in  i  location  with  potentially 
dynamic  implications.  In  mctanics  which  have  a  version  number  which  is  greater  than  one  these  elements  may  appear 
in  the  Picnire  Descriptor.  Use  of  these  elements  in  the  picture  body  is  discoursged  in  order  to  improve  the  potubiliiy 
aid  predictability  of  COM  exchaige. 
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Add  sub-clause  DJ2.22 

It  is  recommended  that  the  mandatory  elemenu  in  the  Metafile  Descriptor  are  written  fiisi  in  the  desriptor  and  in  the 
following  order 

METAFILE  VERSION 
METAFILE  ELEMENT  LIST 
METAFILE  DESCRIPTOR 
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Sub-elauM  DAJ:  repiaee  the  scmaace  with  the  following  tesc 

DEVICE  VIEWPORT.  DEVICE  VIEWPORT  SPECIFICATION  MODE  DEVICE  VIEWPORT  MAPPING 
In  the  ewi  where  the  VC  speeiflar  in  DEVICE  'VIEWPORT  SPECIFICATION  MODE  is  set  to  either  millimetres  with 
scale  factor'  or  'physkai  device  unita'  not  all  mterpieters  may  be  able  to  interpret  the  DEVICE  VIEWPORT  element  as 
specified,  and  the  interpretation  becomes  impiemaualion  dependent.  Since  the  CGM  does  no  specify  the  behaviour  of  an 
interpreter  in  application  may  wish  to  control  the  VDC-io-devtee  mapping  by  mechanisms  exiemai  to  the  CGM  picture 
description,  for  example  to  include  CGM  pienves  in  documents. 


170 


Pttttl27 


AM  the  following  text  to  the  end  of  the  sub-clxiue  0.4.4: 

Clifiping  Modes 

If  tniensetcn  cannot  handle  the  locus’  clipping  mode  for  LINE  CUPPING  MODE.  MARKER  CUPPING  MODE  or 
ET  C£  CUPPING  MODE,  then  locus  plus  shape'  should  be  used  as  a  fsUback 

Page  127 


Add  the  following  text  to  the  end  of  sub-clause  D.4.4 

If  inteipmen  cannot  handle  clipping  to  the  panlletogram  that  could  result  from  using  CUP  INHERITANCE  value 
intenection'  the  suggested  fallback  is  to  clip  u>  the  minimal  circumsenbing  rectangle.  In  cases  where  multiple 
parallelogTants  might  be  composed  (by  intersection)  to  form  a  general  convex  polygott  interpreters  should  intersect  the 
ctreumsenbing  rectangles  to  doive  an  effective  clip  rectangle. 

Page/27 


Add  the  following  text  to  the  end  of  the  APPEND  TEXT  recommendations: 

Changiitg  the  TEXT  PRECISION  in  ptrual  text  state  is  likely  to  lead  to  unpredictable  results.  Generators  are 
discouraged  from  dotng  this.  Interpreters  which  can  otherwise  hsndic  text  attribute  changes  ui  partial  text  state  should 
ignore  this  element  in  that  state  u  a  fallback. 

Page i2S 

Sub-clause  D.4i;  Add  the  following  text  between  CIRCULAR  ARC  CENTRE  CLOSE  »nd  Elliptical 
elements: 

aRCUlAR  ARC  CENTRE  REVERSED 

If  the  Stan  ray  and  end  ray  coincide,  it  is  recommended  that  the  interpreter  draw  the  full  circle. 

•••••••••••••••clause  D.4.5  -  anythini  on  closed  figs  •••••••••••• 
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Add  the  following  sub-clause  after  sub-clause  D.4.8 

D.4.9  Segment  elements 

The  restncuon  of  segment  aoribuies  to  be  set  only  immediatly  after  the  BEGIN  SEGMENT  element  and  before  any  othe 
element  avoids  any  dynamic  effeca.  If  the  output  device  cannot  adjust  segment  priority  on  mierpretaiion.  segments 
should  be  displayed  in  tnder  of  phonty. 

Page  133 


Sub-ciause  D3.  Change  the  scnience  to: 

- capabilities  listed  in  the  tables  below,  appropriate  to  the  venion  of  the  metafile  they  want  to  support. 

Pat*  133 


Sub-clause  OS.  Change  the  title  for  Table  S  to: 

Table  S(a)  Suggested  minimum  capabilities  for  versitm  1  metafiles 
Page  133 


Sub<lausc  D  J  Add  Cie  following  table  after  Table  S(a) 

Table  Sfb)  Suggested  additional  miniimun  capabilities  for  version  2  metafiles 

Capabiluy  Minimum  Suggested  Inierprtiir  Support 
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device  VIEWTORT  SPECmCATION  MODE 
DEVICE  VIEWPORT  MAPPING 


LINE  REPRESENTATION 
marker  R^EPRESENTATION 
TEXT  REPRESENTATION 
FILL  REPRESENTATION 
EDGE  REPRESENTATION 
UNE  CLIPPING  MODE 
MARKER  CUPPING  MODE 
EDGE  CUPPING  MODE 


frictien  of  (hwing  narface 
not  farad,  forced 
left,  conre.  ri|ht 
boBom.  centre,  lop 


locus,  shape;  locus  then  shape 
locus,  shape;  locus  then  shape 
locus,  sha^  locus  then  shape 
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The  following  annex  fomu  a  new  annex  F. 

F  Formal  Grammar  of  the  Functional  Specification  of  the  CGMADDl  Category 
F.l  Introduction 

Thu  granunar  is  a  formal  definition  of  a  standard  CCM  extended  syntax.  The  encoding-independent  and  the  encoding- 
dependent  productions  are  separated,  and  there  are  subsections  showing  the  tyniax  of  each  of  the  standardized  encoding 
schemes.  Oeiails  on  the  oKo^g  of  terminal  symbols  can  be  found  in  paru  of  this  Standard  that  deal  with  the  parucuiar 
encoding  schemes. 

F.2  Notation  used 

<symboI> 

<SYMBOL> 

<symbol>* 

<symbol>»  - 
<symboL>o 
<symbol>(n) 

<symbol-I>  "=  <aymbol-2> 

<symbol-l>  I  <symbol-2> 

<symbol:  meaning> 

(oomment) 

F.3  Detailed  grammar 
F.3.1  Metafile  structure 


<metafl]e> 

<flEGIN  metafiles. 

<metanie  idenufier> 
^mesafOe  descripur^ 
<metafile  comenu>* 

<END  METAHLEs 

^metafile  idenufier? 

<stnng> 

<mciafllc  conients> 

<exaa  element* 
cpientro 
eexora  element* 

<cxira  eiemeiu> 

1 

<extemal  eiemeni> 

<c9cspe  element 

<picmre> 

<BECIN  PICTURE? 

<picOR  idoutfia? 
<picture  deacripior  element* 
<flECIN  PICTURE  BODY? 
<picsire  comeriD* 

<£ND  PICTURE? 

<piccure  !denufler> 

<siring> 

<picrure  co.ntcno 

.T* 

1 

cpicture  element? 

<segmcm? 

<picturc  clemeno 

1 

1 

1 

1 

<eligibie  control  element? 
<gpaphical  element? 

<clcsed  figure? 

<primiiive  attribute  element? 
<pattcm  table  elemeno 

-  nonterminal 

-  terminal 

•  0  or  more  occurrences 

•  I  or  more  occurrences 

-  optional  (0  or  1  occutraKes) 

-  exactly  n  occurrences.  nw2.3.... 

•  symbol- 1  has  the  syntax  of  symbol-2 

-  symbol-1  or  alternatively  symboi-2 

-  symbol  with  the  stated  meaning 

•  explanation  of  a  symbol  or  a  production 
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<segjnent> 


I  <coiour  table  eUmem> 

I  ^specification  eknicno 
I  <segmcmeoni»leietnaii> 
t  <excra  ekincnt> 

=-  <BECIN  SEGMENTS 

occmem  idenofieo 
<x^pnau  attribute  ekineni>* 
<eiigiUe  picnse  e]einen&* 
<£NDSECMENT> 

<segment  ideniiTim  <naine> 

<eligible  picture  elemeno  ^  <eiigible  control  element? 

I  <graphical  element 
I  ccioted  figure? 

>  cprimiiive  attribute  element? 
I  <specincaiion  element? 

I  <segment  control  element? 

I  <extra  element? 

FJ.2  Melaflte  descriptor  elements 


■cmetafile  descriptot?  <estra  element?* 

<identification? 

coptional  descriptor  element?* 


change  next  bit  to  be  lilcc  CGM  ie  no  order  mandated  -  how  to  do  this?' 


<idenuricauon? 

<MBTAF1L£  VERSION? 

<integei? 

<exn  element?* 

<element  list? 

<cxtreeiemen&* 

<mesafi]e  deacripiion?o 

cmetaTiIe  description? 

<METAFTLE  DE.'CRIPTION? 
string? 

ceiement  list? 

1 

<METAnL£  ELEML'.T  L’ST? 

<elemeni  name?* 

<element  name  sborut.  td  enumerated?* 

ceiement  name  shorthand 

Btumerated? 

1 

1 

1 

1 

<DRAWINC> 

<ORAWING  PLUS  CONTROL? 

<VER^  STATIC  ALL? 

<EXTENDED  PRIMITIVES? 

<VER^  STATIC  CKSM? 

<opuonaJ  descT  eimt? 

1 

1 

1 

1 

<VDCTyPE? 

<«de  type  enumerated? 

<MAXIMUM  COLOUR  INDEX? 

<ooiour  index? 

■eCOLOUR  value  EXTENTS 
<red  green  bhiB?{2) 

<METAnLE  DEFAULTS  REPLACEMENT? 
<element  default?-*' 

<FONT  UST? 

<fom  name?-*- 

I 

1 

■cCHARACTER  set  UST? 

ccharacter  set  dermiiion?-*- 
cCHARACTER  CODING  ANNOUNCER? 
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<codiii(  lechnque  «aunienied> 

I  <scaltf  praeisian> 

I  -(MAXIMUM  Vtx:  EXTENT> 
<potiu>  (2) 

I  -(SEGMENT  PRIORITY  EXTENT> 
<tninimttni  exteno 
ontxinniin  exieni> 

I  <segmen& 
t  <exira  elemeno 

<vdc  type  enuinented>  s*  <IN7EGER> 

I  <REAL> 

<element  default  <eligib!e  control  element> 

I  <picnn  dcKhpiar  eianenD 
i  <pnmitive  tuihbute  elemeno 
I  <iegment  amibute  elanent> 

I  <extn  eiemeno 

••••••••••■•  in  uS632  only  escape  allowed  above  not  extra  -  what  is  right?**** 


<foni  nanie> 

<charKter  set  definitions 


<index> 


estandard  index  values 
<non-negative  integers 
<positive  integers 
<pnvue  index  values 
^tegative  integers 
<pos>uve  indexs 

<char  set  enumerxteds 


<ooding  technique  enutneraiods 


edesignation  sequences 
-(scalar  precisions 


<strings 

<char  set  enutnerateds 

edesignation  sequences 

<standard  index  values 
I  ^private  index  values 

7<i  <non-negaiive  integers 
=»  eintegers  (greater  or  equal  to  0) 
se  <inieger>  (greater  than  0| 
^legaiivc  imagers 
<imegers  (less  than  0| 

=>  <positive  integers 

3*  -c94  CHARS 
I  -(96  CHARS 
I  -(MULTI-BYTE  94  CHARs 
I  <MULTI-BYTE  96  CHARs 
I  -(COMPLETE  CODES 

3*  <BASIC7.BrTs 
I  -(BASICS-BITS 
I  -(EXTENDED  7-Brr> 

I  -(EXTENDED  8.Bm> 

esihngs 

-(INTECER  PRECISIONS 
einiegcr  precision  values 
I  (REALPREQSlONs 

ereai  precision  values 
I  -(INDEX  PREQSIONs 

<index  precision  values 
I  <COLOUR  PREQSIONs 

(colour  precision  values 
I  -(COLOUR  INDEX  PREQSIONs 
(colour  index  precision  values 
.  (NAME  PRECISIONS 

(name  precision  values 
( these  elements  have  encoding ) 
{dependent  parameters  ) 
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<poim>  - 

•aninimum  extent  :: 

cnaxiinum  exteno  n 

FJJt  Picture  descriptor  eicmeiits 
cpicture  descriptor  element  s 


'  <V<ICVsisM><2) 

><integer> 

><ime(C)r> 


<jpocifieation  elcmeno 


<colour  scioci  mode  enumeraic(l> 

<scaiing  spec  mode  enumerated^ 

<mecnc  scale  factoid 
cisouopy  flag  cnumcraied> 

<itariz  align  flag  enumer> 

•evert  align  flag  enumer> 


=»  eSCAUNG  MODE> 

ocaling  spec  mode  emimeraied> 

<raetric  scade  fectai> 

I  <VDCEXrENT> 

<poim>(2) 

I  <DEVlCEVIEWPORT> 

<viewpott  poira><2) 

I  <DEVICE  VIEWPORT  SPECIFICATION  MODE 
<VC  specifier  enu>ncnted> 
onetric  seek  factor* 

I  <OEVICE  VIEWPORT  MAPP1NG> 
<uocrapynag  tro)inenied> 

<barai>ntal  alignincni  flag  enutngaied> 
<venical  alignment  flag  enumerated^ 

I  <flACKGROUNDCOLOUR> 

^edpeenbluo 
I  <specifieaiaon  elemeni> 

I  erepreaentaaott  element 
I  epatiem  table  elemani^ 

I  <colour  table  elcmenc* 

I  <extra  eiemeno 

=»  <COLOUR  SELECTION  MODE> 

*  <colour  select  mode  enMtneTaiect> 

I  <UNE  WIDTH  SPECIFICATION  MODE? 

*spec  mode  enumeratet^ 

I  <MARKER  SIZE  SPECIFICATION  MODE? 

*3poc  mode  uiuinaaiet^ 

I  <EDCE  WTOTH  SPECIFICATION  MODE? 

<ipec  mode  enumeratec^ 

3.  <JNDEXED> 

I  <DIRECr> 

=*  cABSTRACT? 

I  <MErRlC? 

z*  ^eal> 

<J^OT  FORCED? 

I  <FORCED> 

=■  <LEFr> 

I  <CENTRE> 

I  <RICKD» 

=■  <BOTTOM> 

I  cCENTRE? 

I  cTOP? 


<spec  mode  enumerated? 


•  <ABSOLUTE? 
t  <SCALED> 


<N-ie»-pon  point? 


:?«  <vp> 
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<vp> 


<VC  specifier  en)unerated> 


■cepresentetiorr  elemeno 


<size  veJuo 

<J>on-negauve  vdc  vaiuo 
^Mn-negauwe  reai> 
<colour> 

<iest  fncision  enumcTaiod^ 

<intenor  style  esnifnented> 


<integer>  (2) 

I  <ie«l><2) 

<FRACnON  OF  DEFAULT  DRAWING  SURFACE> 
I  <MILL1METRE' WITH  SCALE  FACTOR> 

I  <PHYSICAL  DEVICE  UNITS> 

=»  <LINEREPRESENTATI0N> 

positive  index> 

<indfs» 

<size  valiie> 

«»ioui> 

I  <MARKER  REPRESENTATION> 

<posittye  index> 

<index> 

<size  value> 

<colour> 

I  -^TEXT  REPRESEIsrrATION> 

<posiuve  mdex> 

<po»iiive jndea>  (font} 

<text  pncision  enumerated^ 

<***!>  Ichiracter  spacing) 

( expansion  factor  I 
<coloui> 

I  <F1LL  REPRESENTATI0N> 

^positive  index> 

<intenor  style  arumeraied> 

<coiour> 

<in<le)t>  (hatch  index.} 

<poxjtive index>  (panem  index) 

I  <EDGE  REPRESENTATION> 

^positive  index>  « 

<index» 

<sizeva]ue> 

<coloui> 


=3  «ion-negaiive  vdc  value> 

I  'Qion-negadve  reai> 

<vdc  valuo  (treater  than  or  equal  to  0) 

<real>  ( greater  than  or  equal  to  0) 

<colour  index> 

I  ^ed  green  biuc» 

<STRING> 

I  <CHARACTER> 

I  <STROKE> 

=»  <HOLLDW> 

I  <SOLID> 

I  <PATTERN> 

I  <HATCH> 

I  <EMPTY> 


F.3.4  Control  elements 
<control  ciemeno 


<eiigible  control  element> 
I  <BEGIN  FIGURE^ 

I  <ENDnCURE> 

I  <NEWRECION> 


177 


<eljgible  coniTol  elemem? 


<point  lao' 

<poim  p»ii  !ut> 
<point  puT> 

<pomi  edge  p«ir> 
<pomt  edge  paor  luc> 
<edge  out  n*g> 


<icii  e'tcmcr.o 


<rss!r:c:;t5  lex:  eierrenD" 


<tx!er.c> 


<tex:  uil? 


<r«ii  charauar  ;Uo 


<r,onr:ruJ  ;.“'.afac!eT  uji;> 


<jparr.ec  'jlxo 

<ce!l  eieir.cno 


<!ocal  colour  procistoTU* 


<gdp  eiemer.o 


<gdp  tdcnia'ieo 
crecansic  eiemcno 


<pomt>* 
cpotni  poiTS* 

:?•  <pointX2) 

<poinc><adgc  out 

o  <pom  edge  pair>* 

<INVTSIBLE> 

I  <V1S1BL£> 

!  <close.ikvisible> 

!  <CUME_V1SIBL£> 

r-  <TEX7V 

<poinc> 

<iext  ujL> 

crestnetod  text  etemeno 

r-  <RE5TRICrEDTE3(T> 

<exienc> 

<potno 
<utxt  uil> 

r=  <vdc  vaJuexT) 

cfmaJ  chanaer  lito 

<nonrm»ich«cteT  luo 

Ta  <FINAL> 

<atnng> 

ra  <NCrr  FINAL> 

i«t  umbwie  elements* 
<jparmcd  tcjto 

.-a  <APPEVDTEXT> 

<texi  uit> 

•a  <CELL  ARRAY> 

<pox;B>(3) 

<inie|trKi) 

<loc*l  ootow  prmawn^ 

X  miegerZ) 

[  thia  etemcm  hat  an  encoding  j 
Idepsidenparemeur  ) 

ra  <cokow  pi  Butiwi  v«hte> 

I  <oolow  mdea  precisican  vahio 

I  <defau;i  ooiow  precision  indicawr* 

^  <CDP> 

<|dp  idenQrier> 

<poim  lisD' 

<daarecar(t> 

la  euiteger> 

a.  <RECTANGL£> 

<point  pair> 
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<csrulw  doneno 


<CTRCLE> 

<potm> 

<rKiiua> 

t  <CIRCULAR  arc  3  POrNT> 

<poimX3) 

I  <CIRCULAJIaRC3P0INTCL0SE> 

<poiBt>0) 

<tk»«(ype> 

I  <CIRCULAR  arc  CEJJTRE^ 

<pomo 
<*«fc  v*kio{4) 

<ndiuK> 

I  <CIRCULAR  arc  CENTRE  CLOSE> 

<po(nc» 

<vdc  vttue><4) 

<ndiui> 

<clo»«  type> 

I  <CIRCULAR  arc  centre  REVERSED> 
<poini> 

<v<]c  va]|je>(4) 


vtic  vaiue> 


<elc;e  typt>  <PIE> 

!  <CHORD> 

<eilip(icai  eiemeno  ra  <£LLIPSE> 

<pomtX3) 

I  <£LUPT1CALaRC> 
<po«JcK3) 

<^vducX4) 

1  <EUJFnCAL  ARC  CLOSE> 

<po»«cK3) 

<vdc  vdue><4) 

<clau  cypo 

cpoffiiies*  eiemeno  r=.  <CONNECnNC  EDCE> 


FJ.6  Atirlbutt  «ltm«nt5 
<prumuve  iitnbute  elemeno 


dine  ittnbutc  eiemeno 


^marker  aitribviie  elctncno 


<Jine  tnhbuie  elaneno 
I  <3naiiu>  lonbaie  element 
I  <uxiumbiui«itmeit> 

I  ^fiOod-em  wnbute  etoneno 
(  <»pact  sotaci  n«p> 

I  <pick  identifieo 

:?•  <LINEBUN1X£INDEX> 

<potidv«  indco 

I  <LINETYre> 

I  <LINEWIEfrH> 

<gUM  vihK> 

I  <IJNECOUDUR> 

<colo«tf> 

<MARKER  BUNDLE  INDEX> 

<po*iu»«  in<l«> 

I  <MARKERTYPE> 

<]nde«> 

I  <MARKERSI2E> 


180 


<t**t  aunbuie  etemenc* 


•««(  icffibute  eiemeno 

<chv  atmbuu  eiemeno 


cioing  atthbuie  eJemeno 


<p»th  enumerated? 


<Jionzonuil  align  enumerated? 


<sixt  vtiuo 

I  <MARKER  COLOUR? 

'ccotouo 

;3«  ^^TECT  PObrr  INDEX? 

<poi»nv«  index? 

1  <TE(T  PREasiON? 

<a«tprtcaion  emimerued? 

I  <CHARAcrER  expansion  factor? 

^eai? 

I  <CHARACTER  SPACING? 

^ni? 

1  <TEXT  COLOUR? 

<colouo 

I  -eCHARACTlR  HQGHT? 

<3>on-negiiive  vdc  value? 

I  <CHARACT1R  SET  INDEX? 

<pMitive  index? 

I  <ALTERNATECHARaCTER  SET  INDEX? 

<po$»uve  index? 

I  <TEXT  BUNDLE  INDEX? 

^positive  index? 

I  <AUXnjARYCOLOUR? 

<coloux? 

I  <TRANSPARENCY> 

<on-ofr  indicamr  enumerated? 

.-ns  <chxr  inribute  element? 

I  <sthng  aunbute  eiemeno 

=»  <TOCT  BUNDLE  INDEX? 

<positive  index? 

I  <TEXT  PONT  INDEX? 

<poMttv«  index? 

I  <CHARACTER  EXPANSION  factor? 

^eai? 

I  <CHARACTER  SPACING? 

<real? 

I  <TEXT  COLOUR? 

<col<>vit? 

I  <CHARACTiR  HEIGHT? 

q»on-neginve  vdc  value? 

I  <CHARACTER  ORIENTATION? 

<vdc  value?(4) 

I  <CHARACTER  SET  INDEX? 

<ponuve  index? 

I  <ALTERNATECHARACTER  SET  INDEX? 

epondve  index? 

=»  ^TEXTPATH? 

^piili  onmniecb 
I  -^TEXT  PRECISION? 

<axi  pmetrion  emenemad? 

I  cTEXTAUCNMENT? 

<ltOTiXDnial  align  cimmeiatecb* 

<rardcai  align  OQinmated? 

<caTttimious  align  value?  (2) 

:?•  <R1GHT> 

I  <LErr? 

I  <UP? 

I  <DOWN? 

<NORMAL  HORIZONTAL? 
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I  <LEFr> 

I  ^ENTRE> 

I  <RIGHT^ 

I  ■cXNTINllOUS  HORIZOf^AU 

<venic»l  align  enuinen«ed>  <N0RMAL  VERTICAL^ 

I  <TOP> 

I  <CAP> 

I  <HALF> 

I  <BASE> 

I  <BarroM> 

I  -cCOmiNUOUS  VERTICAL^ 
<cominuous  align  value>  ::a  <real> 

<filled  arei  attribute  e!em>  <F1LL  BUNDLE  INDEX> 

<po«iive  indca> 

I  <INTERIOR  STYLE> 

<inienor  style  an>maratc(l> 

I  <F1LLC0L0UR> 

<colour> 

I  <HATCHINDEX> 

<>ndea> 

I  <PaTTERN  INDEX> 

<posiiive  mdea> 

I  <EDGE  BUNDLE  INDEX> 

<pomive  aidea> 

I  <EDGETYPE> 

<indea> 

1  <£DCEWIDrTH> 

<rire  valuB> 

I  <EDCECOLOUR> 

<colour> 

I  <EDGE  VlsiBILrTY> 

<an-«(rindicaior  enumcrauxl^ 

I  <FTLL  REFERENCE  POlNT> 
<poini» 

I  <paiian  table  elemcno 
I  <PATTERN  SIZE> 

<vdc  vtJue>(4) 

<colour  table  element?  <colour  table? 

ouning  index? 

<red  green  blue?-' 

<pattem  table  element?  «;PATTERN  TABLE? 

^oitnv*  iralex? 

<iniega?<2) 

<locat  colour  precision? 
<®olo«?( integer  I  x  inicgal) 

I  this  element  hai  laenccxlingl 
(dependent  parameter  ) 

<startin|  index?  ra  <coiow  index? 

<axpect  source  flags?  <ASPECT  SOURCE  FLAGS? 

<*sf  ptir>» 

<iif  pail?  ;:3  <asf  type  enviinuaiod? 

<asf  enumerated? 

<af  type  enumerated?  :r»  <UNE  TYPE  ASF? 

I  <LINE  WIDTH  ASF? 

I  <UNE  COLOUR  ASF? 
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!  <MARKER  TYPE  ASF> 

I  <MARKER  SIZE  ASF> 

1  <MARKER  COLOUR  ASF> 

I  xTEXT  FONT  ASF> 

I  <TEXT  PREasION  ASF> 

I  <CHARACTER  expansion  FACTOR  ASF> 
I  ^character  spacing  ASFs 
I  <TEXT  COLOUR  ASF> 

I  <INTERIOR  STYLE  ASF> 

I  <F1LL  COLOUR  ASF> 

I  <HATCH  INDEX  ASF> 

I  <PATTERN  INDEX  ASF> 

I  <EDGETYPEASF> 

I  <EDGE  WIDTH  ASF> 

I  <EDGE  COLOUR  ASF> 

<asf  eruincratDd>  :r=  <JNDrVIDUAL> 

1  <BUNDLED> 

<pick  identincr>  :=  <P!CK  IDENTIF1ER> 

<JUine> 


F.3.7  Closed  figure  element 


<e;os«d  figure^j  <BEGIN  FIGURE? 

<eUgible  elemcnu  wtihin  closed  figures? 
<END  RGURE? 


ceiigjble  eiemenu  widiin 

closed  figures?  .r»  <VDC  REAL  PREOSION? 

I  cVDC  INTEGER  PREaSION? 

I  -^auxiliary  COLOUR? 

I  -(TRANSPARENCY? 

I  <ENDncURE? 

I  <NEWREaON? 

I  cPOLYUNE? 

I  <DISJOINT  POLYLINE? 

I  <POLYCON? 

I  -cPOLYCON  SET? 

I  -eCDP? 

I  <RECTANCLE? 

I  -^HRCLE? 

I  <CIRCULAR  arc  3  POINT? 

I  <aRCULAR  ARC  3  POINT  CLOSE? 

I  -eCIRCULAR  ARC  CENTRE? 

I  -^CIRCULAR  ARC  CENTRE  CLOSE? 

I  <aRCUlAR  ARC  CENTRE  REVERSED? 
I  <ELLIPSE? 

I  'jELUPTICALARC? 

1  <ELUPT1CAL  ARC  CLOSE? 

I  <EDGE  BUNDLE  INDEX? 

I  <EDGETYPE> 

I  <EDCE  WIDTH? 

I  <EDGE  COLOUR? 

I  <EDGEVISIBILrrY? 

I  <EDCE  aspect  SOURCE  FLAGS? 
t  <E5CAPE? 

I  <M  ESS  age? 

<APPUCATION  DATA? 


F.3.8  Escape  elements 


cescape  element? 


<escape? 
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<ielentin«r> 

FJ.9  Exttrnal  elements 
<exteTnsi  e)anent> 


<acjjon  n»g> 


F.3.I0  Segment  elements 


<idaiu/ier» 

«(lauraooRt> 

<inte|er> 


<MESSAGE> 

action  flsg> 

<iinn|> 

I  <APPUCATION  DATA> 
<»n(e|er> 
oteumooitib 

<YES> 

I  <NO> 


<segmeni  control  element 


<segm«Tit  itmbuie  elemeno 


<segment  idemifieo 


I 


I 


<SECMENTTR  ^'ISFORMaTION> 
•fscfnmti  I..  -ufier> 
orsnifonr.  'nmainx> 

I  <SECMENTH1C  lUCHTTNC? 

o^ment  idcnultcr> 

eaiuncriie(t> 

I  <SEGMENT  DISPLAY  PR10Rm'> 

•aejmeni  identiflo 
■aejment  dispisy  pnon(y> 

I  <SEGMENTPICKPR10RrrY> 

'^segment  name> 

<segmeni  pick  phoruy> 

^namo 


<*etmeni  idenu/ler> 

<copy  transfonnation  mun.t> 
<seginent  irans/onnauon  applic»iJon> 
<INHERrrANCE  HLTER> 

<fi]ter  selection  list  emmieT»te<l>* 
<seiQng  enuineniecl> 

<CIJP  rNHERjrTANCE> 

<ciip  tnhcRunce  enumenied> 


<copy  traufonnstion  matrix? 
<trinsfonnaoon  matrix? 

<segmeni  trans.  application? 

<Clier  selection  list 

enumerated? 


<aitnbute  and  control 
name  enumerated? 


csransfonnaiion  matrix? 

<2x2  matrix  of  reals? 
<2x  I  matrix  of  vdcs? 

=»  <NO? 

I  <yES? 


<atihbuta  and  conrol  name  emmeraied? 

I  cattnbuie  group  and  control  enumerated? 
I  <ASF  name  enumerated? 

I  <ASF  group  enumerated? 


<LJNE  B  UNDLE  INDEX? 
I  <LJNETYPE? 
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<anr.bviie  group  enumerated? 


<setung  enumenied? 

<asf  name  enumerated? 


<UNEWIimt> 

<UNE  COLOUR? 

<LINE  CUPPING  MODE? 

<marker  bundle  index? 
<marker  type? 

<MARK£R  size? 

<maricercol~ur? 

<MAR1C£R  CUPPING  MODE? 

<TEXT  BUNDLE  INDEX? 

^TEXT  PONT  INDEX? 

<TEXT  PRECISION? 

■cCHARACTER  EXPANSION  FACTOR? 

<character  spacing? 

•^TEXT  COLOUR? 

<CHARACTER  HHGHT? 
<CHARACTER  ORIENTATION? 
<TEXTPATH? 

<TEXTAUGNMENT? 

<FILL  BUNDLE  INDEX? 

<INTERIOR  STYLE? 

<nLL  COLOUR? 

<HATCH  INDEX? 

<EDGE  BUNDLE  INDEX? 
<EDGETYPE? 

<EDGE  WIDTH? 

<EDGE  COLOUR? 

<EDGEVISIBILrTY? 

<EDGE  CUPPING  MODE? 

<PILL  REFERENCE  POINT? 

<PATTERN  TABLE? 

-ePATTERN  SEE? 

<AUXIUARY  COLOUR 
•OTIANSPARENCY? 


•eUNEATTRIBUrES? 

I  BARKER  ATTRIBUTES? 

'  <TEXT  attributes? 

I  <CHARACTER  ATTRIBUTES? 
I  <FILL ATTRIBUTES? 

I  <EDGE  ATTRIBUTES? 

I  <PATTERN  ATTRIBUTES? 

I  <OUTPirr  CONTROL? 

‘  <PICK  IDENTIFIER? 

I  <ALL  ATTRIBUTES? 

I  <ALL? 


<STATE.LIST? 

I  <SECMENT? 

<LINE  TYPE  ASF? 

I  <UNEWIDTHASF? 

I  <LINE  COLOUR  ASF? 

I  <MARKER  TYPE  ASF? 

I  <MARKER  SIZE  ASF? 

I  <MARKER  COLOUR  ASF? 

I  <TEXT  PONT  INDEX  ASF? 

I  <TEXT  PREQSION  ASF? 

I  <CHARACTER  EXPANSION  FACTOR  ASF? 
I  <CHARaCTER  SPAONG  ASF? 

:  <TEXT  COLOUR  ASF? 
i  <INTERIOR  STYLE  ASF? 

I  <nLL  COLOUR  ASF? 

'  <HATCH  INDEX  ASF? 
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<as[  group  animented> 


I  <PATTERN  INDEX  aSF> 
I  <EDCETYPEASF> 

I  <EDCEWIDrrHASF> 

I  <EDGE  COLOUR  ASF> 

=»  <LJNE  ASFo 
I  <MARKERaSFS> 

I  <^rEXTASFS> 

I  <FILLASFS> 

I  <£DCEASF5> 

I  <ALLASFS> 


<cljp  mhenunce  enximerau(l> 

<highlighung  enumeraied:> 

<segmcm  dirplay  pnority> 
<5egment  pick  prioriiy> 


r=>  <STATE_LOT> 

<INTERSECnON> 

<NORMAL> 

I  <HICHUGKrED> 

<imcger> 

<uileger> 


F.4  Terminal  symbols 

The  following  are  the  terminaia  in  this  grammar. 

Their  re^iaeniauon  ia  dependent  on  the  encoding  scheme  used. 

In  amea  A  of  the  subsequent  paru  of  this  Standard,  these 
encoding-dependent  symbols  are  further  descnbed. 

<e!ement  name> 

<integer> 

<reai? 

<vdc  vaiue:> 

<sirirg> 

<colour  indea> 
end  green  blue> 
einteger  precision  valuo 
<7eal  precision  valuer 
<tndea  precision  value? 
ccolqpr  precision  value? 

<col  index  precision  value? 

<name  precision  value? 

<defsult  col  precision  indicator? 

<vdc  intego'  precision  value? 

<vdc  real  precision  value? 
edata  record? 

<namc? 

oiewpon  poino 
<2x2  maoix  of  reals? 

<2x1  masix  of  vdc? 

The  COM  extended  opcodes  are  etKoding  dependent.  A  complete  list  of  them  can  be  found  in  the  productions  for 
<elemem  name  enumerated?  below. 


The  enumerated  types; 

<INTEC«> 

<real? 

<0N> 

<OFF> 

<INDE.\ED> 
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<DIRECT> 

<ABSTRACT> 

<METRIC> 

<ABSOLim> 

<SCALED> 

<94CHAR> 

<9«CHAR> 

<MULT1-BYTE  94  CHAR> 

<MULTI-BYTE  96  C:HAR> 
xCOMPLETE  CODE:> 

<BASIC7.Brr> 

<BASIC  »-BIT> 

<c£XTENDED7-Brr> 

•^EXTENDED  8-BrT> 

<FRACnON  OF  DEFAULT  DEVICE  VlEWPORT> 
<MILLLMETRES  WITH  SCALE  FACrOR> 
<PHYSICAL  DEVICE  UNITS> 

<NOT  FORCED> 

<FORCED> 

<LEFT> 

<RICHT> 

<CENTRE> 

<BCnTOM> 

^OP> 

<LOCUS> 

<SHAPE> 

<LOCUS.THEN.SHAPE> 

<INV1SIBLE> 

<VISIBLE> 

<CLOSE_INVISIBLE> 

<CIjOSE.VTSIBL£> 

<PIE» 

<CHORD> 

<FINAL> 

<NQT  FINALS 
•INDIVIDUAL? 

<BUNDLED> 

<HOLLOW> 

•eSOLID? 

•ePATTERN? 

<HATCH> 

<EMPTY> 

<STRINC> 

■eCHARACTER? 

<STROKE? 

<UP> 

<DOWN> 

<NORMAL  HORIZONTAL;? 

<CONnNUOUS  HORIZONTAL? 

FORMAL  VERTICAL? 

<CAP> 

<HALF> 

<BASE? 

<CONnNUOUS  VERTICAl^ 

<YES> 

•cNO? 

<LINE  TYPE  ASF? 

<LINE  WIDTH  ASF? 

<L1NE  COLOUR  ASF? 
cMARKER  TYPE  ASF? 

<MARK£R  SIZE  ASF? 

^MARKER  COLOUR  ASF? 

<TEXT  FONT  ASF? 

<TEXT  PRECSION  ASF? 
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<charactir  expansion  factor  ASF> 
<character  spacing  ASF> 

<TEXT  COLOUR  ASF> 

<INTERIOR  STYLE  ASF> 

<HATCH  INDEX  ASF> 

<PATTERN  INDEX  A'^'> 

<HLL  COLOUR  ASF> 

<EDGETYPE  ASF> 

<EDGE  WIDTH  ASF> 

•cEDGE  COLOUR  ASF> 

<LINE  ATTRIBUTES* 

<MARKER  ATTRIBUTES* 

^TEXT  ATTRIBUTES* 

•CHARACTER  ATTRIBUTES* 

<FILL  ATTRIBUTES* 

<EDGE  ATTRIBUTES* 

<PATrERN  ATTRIBUTES* 

•OUTPUT  CONTROL* 

CALL  ATTRIBUTES* 

CALL* 

cLINE  BUNDLE  INDEX* 
cLINETYPE* 
cLINE  WIDTH* 
cLINE  COLOUR* 
cLINE  CLIPPING  MODE* 
cMARKER  BUNDLE  INDEX* 
cMARKEF  type* 
cMARKE;-.  .-:/.£* 
cMARKER  COLOUR* 
cMARKER  CUPPING  MODE* 

•iTEXT  BUNDLE  INDEX* 

-dEXT  PONT  INDEX* 
cTEXT  PRECISION* 

ccharacter  expansion  factor* 
ccharacter  spacing* 

CTEXT  colour* 

ccharacter  HHGHT* 

•character  orientation* 

cTEXT  path* 
cTEXT  AUGNMENT* 

•character  set  index* 
calternate  character  set  index* 

cRLL  BUNDLE  INDEX* 
cINTERIOR  STYLE* 
cFILL  COLOUR* 
cHATCH  INDEX* 
cPATTERN  INDEX* 
cEDGE  BUNDLE  INDEX* 
cEDGETYPE* 
cEDGE  WIDTH* 
cEDGE  COLOUR* 
cEDGE  VISIBILITY* 
cEDGE  CUPPING  MODE* 
cFILL  REFERENCE  POINT* 
cPATTERN  SEE* 
cAUXIUARY  COLOUR* 

•transparency* 

cSTATE.UST* 
ciNTERSECnON* 
cSEGMENT* 
cUNE  ASFS* 
cMARKER  ASFS* 
cTEXT  ASFS* 
cRLL  ASFS* 
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<cEDGE  ASFS> 
<ALL  ASFS> 
<NORMAL> 
<HICHLICHTED> 


<eiemai(  nime  enumenset^ 


=  <BEGIN  METAFILE* 

I  <END  METAFILE* 

I  <BEGIN  PICTURE* 

I  <BECIN  PICTURE  BODY* 

I  <END  PICTURE* 

I  <BEGIN  SEGMENT* 

I  tEND  SEGMENT* 

I  <METAFILE  VERSION* 

I  <MErAFILE  DESCRIPTION* 

I  <VDCTyPE* 

I  ^INTEGER  PRECSION* 

I  <REAL  PRECISION* 

1  <INDEX  PRECTSION* 

I  <COLOUR  PREQSION*  • 

I  -COLOUR  INDEX  PREQSION* 

I  <NAME  PRECISION* 

I  <;MAXIMUM  COLOUR  INDEX* 

I  -COLOUR  VALUE  EXTENTS 
I  -AIETAFILE  ELEMENT  UST* 

I  ^metafile  DEFAULTS  REPLACEMENT* 

I  <FONTLIST* 

I  -CHARACTER  SET  LIST* 

I  <CHARACTER  CODING  ANNOUNCER* 

1  <MAXIMUMVOC  EXTENT* 

I  <SECMENT  PRIORITY  EXTEI^* 
i  <SCAL1NG  MODE* 

I  <COIjOUR  selection  MODE* 

I  <UNE  WIDTH  SPECIFICATION  MODE* 

I  <MARKER  SIZE  SPEaFICATION  MODE* 

I  -tEDGE  WIDTH  SPECIFICATION  MODE* 

I  <VDCEXTENT» 

I  ^BACKGROUND  COLOUR* 

I  <DEVICE  VIEWPORT* 

I  <OEVICE  VIEWPORT  SPECIFICATION  MODE* 
I  <DEVICE  VIEWPORT  MAPPING* 

I  <UNE  REPRESENTATION* 

I  <MARKER  REPRESENTATION* 

I  -TEXT  REPRESENTATION* 
i  <nLL  REPRESENTATION* 

I  <EDGE  representation* 

I  <VDC  INTEGER  PRECISION* 

I  -:VDC  REAL  PRECISION* 

I  -AUXILIARY  COLOUR* 

I  -transparency* 

t  -CUP  RECTANGLE* 
f  <CUP  INDICATOR* 

I  -LINE  CUPPING  MODE* 

I  -MARKER  CLIPPING  MODE* 

I  <EDGE  CLIPPING  MODE* 

I  <fiECIN  FIGURE* 

I  -:ENDRGURE* 

I  <NEW  REGION* 

I  <SAVE  PRIMITIVE  CONTEXT* 

I  <RESTORE  PRIMmVE  CONTEXT* 

I  -sPOLYUNE* 

I  <DIS  JOINT  POLYLINE* 

I  <POLYMARKER* 

I  -TEXT* 
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I  <REST1UCTE0TEXT> 

I  -«APPENDTEXT> 

1  <P0l.Y<30N> 

I  <POLYGON  SETS- 
I  <CEU,ARRAY> 

I  <GOi>:» 

I  <RECTANGLE> 

I  <aRCLE> 

I  <CIRCULAR  arc  3  POINT> 

I  <CIRCUL\R  arc  3  POINT  CLOSED 
I  <CIRCULAR  arc  CENTRE> 

I  <C1RCULAR  ARC  CENTRE  CLOSE> 

I  <CIRCULAR  arc  CENTRE  REVERS£D> 
I  <EUJPSE> 

I  “cELLIPTICALARO 
I  ^ELLIPTICAL  ARC  CLOSE> 

I  ^CONNECTING  EDGE> 

I  <LINE  BUNDLE  INDEX> 

I  <LINETYPE> 

I  <LINEWIDrH> 
t  <UNECOLOUR> 

I  ■^MARKER  BUNDLE  INDEX> 

I  -MARKER  TYPE> 

I  <MARKERS1ZE> 

I  -MARKER  COLOUR> 
t  <TE3Cr  BUNDLE  INDEX> 

I  -^rEXTFONTINDEX> 

>  -^rEXTPREasION> 

I  <CHARACTER  EXPANSION  FaCTOR> 

I  <CHARACTER  SPACINC> 

I  -^rEXTCOLOUR> 

I  ^CHARACTER  HEICHT> 

I  <CHARACTERORIENTAT10N> 

I  <TEXTPATH> 

I  <TEXTALrGNMENT> 

I  <CHARACrERSEriNDEX> 

I  -^ALTERNATE  CHARACTER  SET  INDEX> 
I  <FILL  BUNDLE  1NDEX> 

I  ^interior  STYLE? 

I  <FILL  COLOUR? 

I  -cHATCH  INDEX? 

I  -U»ATrERNlNDEX> 

I  <EDGE  BUNDLE  INDEX? 

1  -;EDGETYPE? 

I  <EDG£WlDrTH? 

I  -fDGE  COLOUR? 

I  <EDGEVlSIBILrrY? 

I  -JILL  REFERENCE  POINT? 

I  -PATTERN  TABLE? 

I  <PATTERN  SEE? 

I  -COLOUR  TABLE? 
i  “^ASPECT  SOURCE  FLAGS? 

I  <PICK  IDENTIFIER? 

I  -COPY  SEGMENTS 
I  ^inheritance  FILTER? 

I  <CLIP  INHERITANCE? 

I  -CLIP  INHERITANCE? 

I  <SEGMENT  TRANSFORMATION? 

I  <SEGMENTHICHLICKnNG? 

I  <SEGMENT  DISPLAY  PRIORITY? 

I  <SECMENT  PICK  PRIORITY? 

I  <PIXEL  ARRAY? 

I  <escape? 

I  <MESSAGE? 
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<APPUCAnON  DATA> 
<DRAWtNG  SEr> 

<DRAWING  PLUS  CONTROL  SEr> 
cVER^  STATIC  ALL  SET> 

<extended  primittves  sets 

<VER J  STATIC  GKSM  SEr> 
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Annex  G  Relationship  of  CGM  and  GKS 

(This  nmex  does  not  fonn  a  pm  of  (he  sundard) 

G.l  Introduction 

The  GKS  Standard  includes  the  concepts  of  raetifUe  input  and  oatput  workstations  u  well  u  functions 
providing  access  to  and  interpretaiian  of  meunies.  It  does  i»l  however,  oonuin  a  metafile  defini’ion  as  part  of  the 
Standard.  Annex  E  of  this  standard  provides  a  mapping  to  version  1  metafiles. 

This  Annex  provides  a  maf^g  between  GKS  and  the  version  2  metafiles. 

G.2  Scope 

The  CGM  Add.2  captures  static  picture  definitions.  GKS  provides  many  possibilities  to  generate  images.  This 
means  :.hat  the  strategies  for  generating  picture  definitions  are  munerous  and  complex.  The  best  strategy  to  use  in  given 
circunuunces  is  dictated  by  implementaiion  and  application  requitemoits.  Tlus  annex  presents  a  detailed  mappings 
between  GKS  and  CGM  only  for  one  particular  strategy. 

The  scope  of  this  annex  is  further  timiied  to  generation  of  metafiles  by  GKS  and  inierpretaiion  of  GKS  generated 
metafiles  in  GKS  environmenu.  There  are  many  ocher  scenarios  for  generation  and  interpretauon  of  metafiles,  such  as 
mterpreution  by  GKS  of  metafiles  not  generated  by  GKS  ml  interpretation  by  non-GKS  processes  of  GKS  generated 
metafiles.  These  scenarios  are  not  dealt  with  in  this  annex.  The  annex  C  presents  context  models  dealing  with  such 
cases. 


GJ  Overview  of  the  Differences  Between  GKS  and  CGM  Version  2 

While  CGM  supports  all  of  the  basic  output  functionality  of  GKS.  a  one-to-one  mapping  between  GKS  and  CGM  vs 
not  possible  in  aU  cases  mainly  because  some  CGM  eiemenu  have  no  counterparts  as  GKS  functions  and  some  GKS 
functions  have  no  corresponding  CGM  elemenL  Examples  of  this  are: 

1.  Delimiter  element  like  BEGIN  PICTURE 

2.  Enhanced  facilities  for  tailoring  and  controlling  the  interpretation  of  the  metafile  precision  of 
various  items,  and  the  control  of  default  values. 

3.  Extended  capabilities  in  the  area  of  text  processing,  such  as  named  font,  changing  character  sets  and 
restricted  text. 

G.4  Mapping  Concepts 

The  tables  later  in  this  annex  present  mappings  between  GKS  and  CGM  eiemenu. 

G.4.1  Principles 

The  following  principles  arc  basis  of  the  GKS/CGM  model  of  this  aistex  and  of  the  function  mappings  themselves: 

a)  conceptual  compa.ubility  with  GKS 

b)  compatibility  with  the  design  concepu  of  CGM 

G.4.2  Workstation 

i  he  COM  is  generated,  ui  this  model,  by  a  worksution  of  type  MO.  The  behaviour  of  the  worksution.  particularly  in 
response  to  dynamic  GKS  functions,  can  be  iHustraied  by  anaJogy:  in  most  respecu.  the  MOATGM  worksution  in 
Gi^  maybe  implemented  in  a  manner  analogous  to  a  woritstaaion  of  category  OUTPUT  (fcg^  a  idotter).  whose  device 
insiruaion  set  corresponds  to  the  COM  elements.  Strategies  for  cortcctly  sending  device  iiuiructions  to  such  a  real 
davice  are  similar  to  those  generating  the  proper  elements  on  the  metafile. 

The  CGM  is  read  by  a  worksution  of  category  MI.  Certain  elements,  sudi  as  the  metafile  descriptor  and  precisiem- 
setung  eiemenu.  are  viewed  as  directivea  to  the  MI  workstation  iuelf.  so  that  it  may  correctly  read  the  metafile  conienu. 

G.4.3  Picture  generation 
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A  mettfile  si  composad  of  *  coUectkm  of  mutuaily  sndeptndani  ptcnrc*.  CKS  docs  noi  h»»f  th*  aincepi  ol  'pictart' 
u  defined  in  CCM  but  it  does  formeUzs  the  nout>n  of  ta  onpty  vtew  turfaoe.  GKS  actions  whicfi  catoe  deair.ni  of  the 
view  surface,  such  as  CLEAJl  WORKSTATION,  m  defmed  so  deiinut  ineufik  picture  There  ss  enother 
mcchasusm  which  leads  la  lencration  of  pKturts  us  this  model  of  the  CKSATCM  teiaisoRshtp.  CKS  conums 
ftmetjons  which  have potendeldyrtanuc effects  cm  anon -empiydiipUy  surface.  The CGM desim esciaoe 
dynamic  modificaiion  of  p  aaes.  For  this  reason  all 'dynamic  modaficatKm  accepted  .* ''slues  oi  *  MO.CCM 
workstation  wtQ  ba  conccpmiaJly  IXG. 

The  default  ''•luc  of  the  dcfcrrai  sitic  on  sn  MO/CCM  worfcsution  is  ASTI -SUPPRESSED 

This  model  of  the  MO/CCM  workstation  defines  that  whenever  a  GKS  hmcuon  n  involmd  which  causa  a  rcjeneriiion 
then  a  picnsre  is  output  to  the  metafile. 

G.4.4  Coordinates  and  clipping 

The  coordinate  space  of  the  metsfilc.  VDC.  is  definod  u  bcin|  idenucail  to  the  NDC  space  of  CKS  Gippirg  and 
iramformauon  are  compteily  deferred  to  the  meuTilc  imcrpracT.  Each  CKS  clip  ano  ^aniformaiion  eior.er;  .-.ai  a 
counterpart  in  CGM. 

G.4.5  Workstation  transformation 

The  worksuQon  cransformation  is  defined  in  GKS  by  seaing  a  worksiaiion  window  m  device  indepcr.der;i  S'DC  arc  i 
workstauon  viewport  in  devicc-depcndou  DC.  The  workstation '•nndow  is  wnaen  to  the  metafile  wiuh  the  VDC 
EXTENT  elemenL  The  workstation  viewport  is  wniien  to  the  metafile  with  the  DEVICE  V!E'A"PORT  eiemenL 

The  default  values  of  DEVICE  VIEWPORT  mapping  correspond  to  GKS  mappin|  of  the  device  coordinate 
system  onto  the  dispUy  space-  The  DEVICE  VIEWTORT  SPEaRCATION  .MODE  is  set  lo  vfiLLIMETliES 
WITH  SCALE  FACTOR  and  metnc  scale  factor  lOOO.O  within  the  .METAFILE  DEFAULTS  REPLACEMENT 
ekmeni. 

G.4.7  Metafiie  element  list 

The  meuGle  element  list  short  hand  defined  for  use  with  CKS  application  is  vetsioni  luuc  |lum 

G.4.R  Relationship  of  fonts  between  CGM  and  GKS 

The  CKS  standard  includes  the  concepts  of  teat  output  primitive  aitnbuies.  However,  the  mochamjm  for  rsxcif\i,-.g 
the  text  font  differs  from  that  specified  m  the  CCM  standard.  T>us  clauie  defines  the  approach  to  handling  these 
tnnbuta  within  the  GKS  envtronmenL 

G.4.8.1  Overview  of  the  differences  between  GKS  and  CGM  fonts 

While  CGM  supports  the  TEXT  output  prunuive  atinbuic  funcuonaliry  of  GKS.  a  one-to-one  mapping  berv/een 
CCM  and  CK5  is  not  possible  in  all  caaea.  Spacincally; 

1)  GKS  aid  CGM  differ  in  the  «ey  fonts  we  definesi 

In  the  CGM  teat  fonts  sre  defined  with  the  FONT  LIST  element  that  assoaaies  font  nama  or  identificauons  wuh 
enirtea  us  a  Font  Table. 

In  GKS.  no  mechanism  is  availabk  for  definini  text  fonts.  CKS  associates  a  unique  text  font  number  with  each  font 
The  Registration  Authority  is  respoitsibk  for  defining  this  mappmg  of  font  numbers  to  specific  font  idenuficauoru. 

Z)  GKS  and  CGM  differ  in  the  wey  fonts  are  selected: 

In  the  CCM.  text  fonu  are  selected  with  the  TEXT  FONT  INDEX  element  The  index  selects  an  individual  font  from 
different  fonu  in  the  font  list 

In  GKS.  text  fonu  are  selected  with  a  font  number.  The  font  number  seleeu  a  specific  GKS  regisiered  font  if 
the  value  u  posiuve.  If  the  font  numbCT  is  negative  an  vmplcmcnution  dependent  font  is  selected 

3)  GKS  and  CGM  differ  on  the  independence  of  font  and  text  prension: 
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In  ihe  CCM,  lAt  font  and  text  preasion  ««  spacifiod  by  luhtpendmi  cicitwnu. 

In  CKS.  itw  font  and  lui  precision  are  directly  asaociatod  with  fpeciTicauon  by  a  sii^lc  funaion. 

4)  Some  CGM  Elements  have  no  counterpen  as  CKS  funcaona: 

These  include  /  jtUiary  Colour  related  elements,  well  as  AUXILlAJlY  COLOUR  mtd  T*.V*4SPARENCY  that  affect 
the  preseniaiton  of  ictu. 

This  addidonai  funcdotiality  of  the  CGM  causes  no  special  problems  for  a  CKS  enyiiCBtntent  tmcrpretat  a  version  2 
CCM. 

5)  The  character  let  related  elemenu  CHARACTER  SET  LIST.  CHARACTER  CODING  ANNOUNCER, 
CHARACTER  SET  INDEX.  ALTERNATE  CHARACTER  SET  INDEX  have  no  counierp®!  m  CKS.  CKS  does  not 
recogntze  the  concept  of  chancter  set  w  a  separate  concept  6om  the  font  concepL  CKS  impiementon  are  enoout  aged  to 
provide  a  mapping  to  the  characm  set  ekments  for  both  MO  and  .MI  woritstatioits  to  increase  the  postibiiiry  of 
traniferrmg  metafile  beeween  CKS  environments  and  other  syitcms. 

G.4.8.2  Suggestion  for  interpretation  of  CGM  font  information  by  GKS 

CKS  environmenu  interpreting  a  CGM  specify  fonu  «ith  a  font  number.  It  is  assumed  that  CKS  matmams  a  Ust 
auociaung  positive  fotu  numbers  with  a  GKS  regtstered  font  name  or  ideiuiftcr.  Private  fora  numben  (Le.  negative 
values)  must  be  maintained  in  an  impiemeruauon  dependm  list  of  assoaations.  As  the  FONT  LIST  ekmeru  is 
interpreted,  an  additional  list  must  be  maitttaiiwd  that  aaocsaies  iadividuai  font  names  spenfied  in  the  CCM  with  a 
font  index.  When  the  TEXT  PONT  INOBC  ciemem  is  inurpresad,  the  font  name  associated  with  tha  font  index  is 
dctetmined  from  the  list  of  currently  used  fonts.  The  font  name  is  used  to  dcurmine  the  CKS  font  number  associated 
V  .dt  this  font  fmm  s  list  of  GKS  registered  fonts.  This  font  number  is  used  is  the  font  parameter  of  the  TEXT 
FONT  AND  PRECISION  function.  The  value  of  tha  precision  parameter  is  taken  bom  the  TEXT  PRECISION 
element 

G.4JJ  Geaeraling  CGM  font  information  from  GKS 

When  generatini  font  information  from  GKS  via  TEXT  FONT  AND  PRECISION  it  is  recommended  dui  the 
generator  also  writes  the  elements  CHARACl'kR  SET  INDEX  and  ALTERNATE  CHARACTER  SET  INDEX  as  well 
u  TEXT  FONT  INDEX  and  TEXT  PRECISION.  Tha  gcncruor  is  assumad  ui  have  a  uhic  aasoctaung  the  posiuve 
font  numbers  of  GKS  with  the  regisicred  names.  The  genciiior  shall  put  a  PONT  UST  alament  in  the  .Metafiie 
Descriptor  with  the  names  of  those  fonts  referenoed  by  positive  GKS  fora  numbers.  Negitive  GKS  font  numbers  se 
pnvaie  and  must  be  mapped  u>  CCM  font  indices  which  are  positive  and  beyond  the  rmgc  of  tha  table. 

.NOTE;  The  metafile  must  be  completely  generated  before  the  FONT  UST  ekmcra  cm  be  wnoen. 

G.5  Metafile  Generation 

Included  in  following  tables  is  a  pmicular  set  of  mappings  of  the  GKS  ftmedon.  workstation  state  list  entnes  and 
segment  suie  list  entnes  onto  CCM  elements.  The  mappinp  prerenud  m*  deemed  usable  and  suiiaiHe  for  guiding 
impienenuuon  of  a  CCM  picure  genoaior  in  a  GKS  environment.  The  mapping  concepts  of  G.4  are  assumed. 

G.5.1  Control  functions 

GKS  function  CGM  Add. 2  elensnta  Notes 


OPEN  HORKSTATIC^  BEGIN  METAfTXX  (1) 

(Mstafiln  Ocacxiptor)  (2) 
BEGIN  PIC7DRE  (3) 
Store  current  workstation  state  list  (4) 
BEGIN  PICTURE  BODY 


cicsE  mor.kstat:cn  end  picture 

END  METAFILE 

AC:r,?ATE  >I0RKSTAT:cn  attribute  settings  (5) 

CLIP  RECTANGLE 
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cun?  INDICATOR 

enable  output  to  metafile 


DEACTIVATE  WORKSTATION 

disable  output  to  metafile 

CLEAR  WORKSTATION 

no  Action 

control  flag  -  CONDITIONAL 
display  space  empty  -  EMPTY 

CLEAR  WORKSTATION 

END  PICTURE 

display  space  empty  ■  NOTEMPTY 

BEGIN  PICTURE 

(3) 

store  current  workstation  state  list 
BEGIN  PICTURE  BODY 

(4) 

attribute  settings 

CLIP  RITTANGLE 

CUP  INDICATOR 

(£i 

REDRAW  ALL  SEOJENTS  CN  WORKSTATION  no  Action 
iispiay  space  empty  -  EMPTY 

REDRAW  ALL  SEC^JENTS  ON  WORKSTATION  END  PICTDRE 

(lispiay  space  empty  -  NOTEMPTY  BEGIN  PICTURE  (21 

Store  current  workstation  state  lost  ;■!'< 

BEGIN  PICTURE  BODY 

attribute  settings  ( 2 1 

CLIP  RECTANGLE 
CUP  INDICATOR 

generate  all  visible  segrents  stored  for 

the  MO  workstation  16; 


UPDATE  WORKSTATION 
regeneration  flag  •  PERECRM 
new  frame  action  necessary 
at  update  ••  YES 

UPDATE  WORKSTATION 
regeneration  flag  •  PEPECRM 
new  frame  action  necessary 
at  update  -  NO 
or 

UPDATE  WORKSTATION 
regeneration  flag  •  POSTPONE 

SET  OEFER-RAL  STATE 

new  frame  action  necessary 

at  update  »  YES 

ESCAPE 


as  REDRAW  ALL  SEGMENTS  WORKSTATION 


no  Action 

as  REDRAW  ALL  SEGMENTS  ON  WORKSTATION 


ESCAPE 


MESSAGE 


MESSAGE 


NOTES 

1)  The  use  of  ihe  idenufier  parameter  in  BEGIN  METAFILE  is  impiemenaiion  dependent 

2)  See  G.3  J  Metafile  DescripiDr 

3)  The  use  of  ihe  identifier  parameter  in  BEGIN  PICTURE  is  implementation  dependent 

4)  See  G  .5.6  mapping  of  worksution  state  list  to  CGM  clement 

5)  The  iitnbutc  settings  ensure  that  the  metafile  attributes  in  effect  when  the  first  graphical  pnmiu  ve 
clcnieniof  a  picture  is  encountered  match  the  current  aunbuies  from  the  GKS  sDteiist 

6)  Generated  sequence  of  CGM-EIemcnis  for  every  segment  as  ASSOOATE  SEGMENT  WITH 
.  WORKSTATION  (see  G.5.3.4) 
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G.5.2  GKS  function  leading  to  an  implicit  regeneration 


Depending  on  the  deferral  stale  Uw  following  GKS  fteKtiora  may  act  as  REDRAW  ALL  SEGMENTS  ON 
WORKSTATION  because  ooncepcuaily  all  corresponding  “dynaituc  modifkaaon  accepted ewnes  ui  ihe  woritsunon 
descripaon  table  «e  set  to  IRG  (see  G.4  J) 

SET  POLYUNE  REPRESENTATION 
SET  MARKER  REPRESENTATION 
SET  TEXT  REPRESENTATION 
SET  INTERIOR  REPRESENTATION 
SET  PATTERN  REPRESENTATION 
SET  COLOUR  REPRESENTATION 

SET  WORKSTATION  WINDOW 
SET  WORKSTATION  VIEWPORT 

SET  SEGMENT  TRANSFORMATION 
SET  VISBIUTY 
SETHIGHUCKTING 
SET  SEGMENT  PRIORITY 


all  primitives  added  to  open  segmenu  overlapping  segmenu  of  higher  pnohty. 


DELETE  SEGMENT 

DELETE  SEGMENT  FROM  WORKSTATION 
ASSOCIATE  SEGMENT  WITH  WORKSTATION 


G.5J  GKS  function  with  no  direct  dynamic  elTect 
G.5.3.1  Mappings  of  output  function 


GKS  function 


CGM  Slemant 


Notes 


POLYLINE 

POLYLINE 

POLYMARKER 

POLYMARKER 

TEXT 

TEXT 

FILL  AREA 

FILL  AREA 

CELL  ARRAY 

CELL  ARRAY 

GDP 

• 

GDP 

G.5.3.2  Mappings  of  output  attributes 

GKS  function 

CGM  alentenc 

Notes 

SET  POLYLINE  INDEX 

LINE  BUNDLE  INDEX 

SET  LINETYPE 

LINE  TYPE 

SET  LINTNIDTH  SCALE  FACTOR 

LINE  VflDTH 

(1) 

SET  POLYLINE  COLOUR  INDEX 

LINE  COLOUR 

(2) 

SET  POLYMARKER  INDEX 

MARKER  BUNDLE  INDEX 

SET  MARKER  TYPE 

MARKER  TYPE 

SET  MARKER  SIZE  SCALE  FACTOR 

MARKER  SIZE 

(1) 

SET  POLYMARKER  COLOUR  INDEX 

MARKER  COLOUR 

(21 

SET  TEXT  INDEX 

SET  TEXT  FONT  AND  PRECISION 


TEXT  BUNDLE  INDEX 

TEXT  FONT  INDEX  (3) 

TEXT  PRECISION 
CHARACTER  SET  INDEX 
ALTERNATE  CHARACTER  SET  INDEX 
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(2) 


SET  CHARACTER  EXPANSION  FACTOR 

SET  CHARACTER  SPACING 

SET  TEXT  COLOUR  INDEX 

SET  CHARACTER  HEIGHT 

SET  CHARACTER  OP  VECTOR 

SET  TEXT  PATH 

SET  TEXT  ALIGiaffiNT 

SET  FILL  AREA  INDEX 
SET  FILL  AREA  STTLE 
SET  FILL  AREA  STTPE  INDEX 

SET  FILL  AREA  COLOUR  INDEX 

SET  PATTERN  SIZE 

SET  PATTERN  REFERENCE  POINT 

SET  ASPECT  SOURCE  FLAG 
SET  PICK  IDENTIFIER 


CHARACTER  EXPANSION  FACTOR 
CHARACTER  SPACING 
TEXT  COLOUR 
CHARACTER  HEIGHT 
CHARACTER  CHUENTATION 
TEXT  PATH 
TE>-^  ALIGNKENT 

FILL  BUNDLE  INDEX 
INTERIOR  STYLE 
HATCH  INDEX 
PATTERN  INDEX 
FILL  COLOUR 
PATTERN  SIZE 
FILL  REFERENCE  POINT 


ASPECT  SOURCE  FLAGS 
PICK  IDENTIFIER 


NOTES 

1) 


The  default  specification  modes  SCALED  apply. 

The  default  colour  selection  mode  INDEXED  applies. 

GKS  includes  the  notion  of  character  set  within  font',  whereas  COM  separates  the  two 
concepts.  When  the  value  of  'font'  in  the  GKS  sute  list  changes,  then  the  CGM  elements 
TEXT  FONT  INDEX.  TEXT  PREaSION.  CHARACTER  SET  INDEX  and  ALTERNATE 
CHARACTER  SET  INDEX  are  written  to  the  metafile,  each  with  the  value  of  2ie  font  and 
precision'  entry  in  the  GKS  state  list.  The  CGM  font  index  is  determined  as  desenbed  sub¬ 
clause  G.4.8  JL  The  elements  shall  appear  consecutively  in  the  metafile  but  may  appear  in  any 
order. 

Legal  values  of  the  GKS  'nil  area  style  index'  differ  depending  upon  whether  the  current 
interior  style  is  Ttatch'  or  pattern'.  Therefore  a  negative  GKS  style  index  results  only  on  the 
generation  of  the  HATCH  INDEX  element,  and  a  positive  value  results  in  the  generation  of 
both  the  HATCH  INDEX  and  PATTERN  INDEX  elements. 


G.5.3.3  .Mappings  of  transformation  function 


GKS  function 


OSl  Elesienc 


N’cee  E 


SET  WINDOW 

(of  current  selected 
noraaiisation  transformation) 


CHARACTER  HEIGHT 

CHARACTER  ORIENTATION 

PATTERN  SIZE 

FILL  REFERENCE  POINT 


SET  '/lEWPORT 
(of  current  selected 
normalisation  transformation) 


SET  NORMALISATION  TRANSFORMATION 


CHARACTER  HEIGHT 

CHARACTER  ORIENTATION 
PATTERN  SIZE 
FILL  REFERENCE  POINT 
CLIP  RECTANGLE 

CHARACTER  HEIGHT 
CHARACTER  ORIENTATION 
PATTERN  SIZE 
FILL  REFERENCE  POINT 
CLIP  RECTANGLE 


G.5.3.4  Mappings  of  segment  manipulation  function 


GKS  function 


CGM  element 


Notes 


CSEATE  SECMOT 
CLOSE  SEOiENT 
RENAME  SEQIENT 

ASSOCIATE  SEGMENT  WITH  WORKSTATION 


COPT  SEC21EN7  TO  WORKSTATION 


INSERT  SEaiENT  TO  WORKSTATION 


BEGIN  SEGMENT 
END  SEGMENT 
no  acclon 
BEGIN  SEGMENT 

(se^nanc  attributes  from  the 
se^pnent  state  List) 

(primtives  and  their  associated 
attributes,  clip  rectangle  and  clip 
indicator) 

END  SEQUENT 

(transformed  (1) 

priaatives  and  their  associated 
attributes,  clip  rectangle  and  clip 
indicator) 

(transformed  primitives  and 
associated  attributes)  (2) 


NCTES 

1)  PhmiuvM  emsformed  by  the  segment  eansfonnation. 

2)  Phmiuves  transformed  by  the  segment  transformation  followed  by  the  tnsen  cransformauon. 

G.5.3.5  Mapping.-,  of  segment  attributes 

see  G  J.2.4.  G3.4  and  GJS.7 


G.5.4  GKS  function  with  no  Action 
•••sentence  not  iist'^^^^ 

GKS  fiinction  Notes 


SET  OETECTABLITT 

SET  VIEWPORT  INPUT  PRIORITY 

all  input  function 

ail  inquiry  function 

all  utility  function 

ail  error  handling  function 


G.5.5  Metafile  Description 

At  the  head  of  a  metafile  is  a  sea  of  Metafile  Oescsiptor  (MD)  elements.  It  is  useful  to  view  these  elements  as  forming 
a  Metafile  Desenpoon  Table  (similar  lo  the  GKS  and  Workstaiion  Description  Table  in  GKS). 

In  (he  GKS  contest,  the  following  description  tabic  would  be  written  at  the  beginning  of  a  metafile.  For  the 
elements  which  arc  listed  as  'ijd'.  it  is  implemenution  dependent  both  whether  the  elements  are  inclucMd  in  (he  table  and 
what  values  aft  usigned  to  (he  elements. 

Mscafile  alasnent  List  Eletnanc  Valua  Mandatory 


METAFILE  '/ERSION 

2 

X 

.METAFILE  DESCHdPTICN 

i.d. 

METAFILE  ELEMENT  LIST 

t.d. 

X 

VDC  TYPE 

i..d. 

X 

INTEGER  PRECISION 

i.d. 

REAL  PPXCISICN 

i.d. 

INDEX  .PRECISION 

I.d. 
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COLODR  PRECISION  i.d. 
OJLOUR  INDEX  PRECISION  i.d. 
MAXIMUM  VDC  EXTENT  i.d. 
MAXIMUM  NPC  EXTENT  i.d. 
COLOUR  VALUE  EXTENT  i.d. 
SEGMENT  PRIORITY  EXTENT  i.d. 
METAFILE  DEFAULT  REPLACEMENT  i.d. 
FONT  UST  i.d. 
CHARACTER  CODING  ANNOUNCER  i.d. 
CHARACTER  SET  LIST  i.d. 
global  segsnents  i.d. 


i.d.  >  implcmenuuon  dependent 


METARLE  VERSION.  METAFILE  CATEGORY  wdMETAnLE  ELEMENT  UST  are  mandatory.  All  metafile 
defauJu  satisfy  the  CKS  Descnpuon  Table.  Inclusion  of  the  METAFILE  DEFAULTS  REPLACEMENT  element  to 
change  any  control,  picture  descriptor,  and  attnbutc  defaults  is  opuonal  and  tmplenuuon  dependent  It  is  also 
itnpiemenuuon  dependent  whether  the  COM  generator  includes  any  of  the  other  .MD  elements,  such  as  the  precision 
setung  elements. 


G.5.6  Mapping  of  workstation  state  list  entries  to  CGM  elements 
GKS  workscation  state  list  entry  CO!  element 


reepested  workstation  window 
requested  workstation  viewport 
every  entry  of  polyline  bundle  table 
"  "  "  polymarker  " 

"  "  "  text 

"  "  "  Lnterior 

"  "  “  pattern  cable 

*  -  "  COLOUR 


NDC  EXTENT  C) 

DEVICE  VIEWPORT  (2) 

LINE  REPRESENTATION 

MARKER 

TEXT 

fill 

PATTERN  TABLE 
COLOUR  - 


.NOTES 

1)  The  position  of  Uie  workstation  window  within  the  NDC  unit  square  corresponds  to  position  of  the  VDC 
eaieni  within  the  maximum  VDC  extent. 

2)  DEVICE  VIEWPORT  SPECIFICATION  MODE  and  DEVICE  VIEWPORT  MAPPING  may  be 
specified  only  within  .METAFILE  DEFAULTS  REPLACEMENT  in  the  meuTiIe  descriptor.  The  VSU  spect.Hcr 
may  be  either  millimetres  with  scale  factor  with  metric  scale  factor  1000.0.  or  'physical  device  uiuis'. 


G.5.7  Mapping  of  segment  state  list  entries  to  CGM  Add.2  eiemeats 

GKS  segment  state  list  entry  091  element 


segment  uransfonnation  matrix 
visibility 

SEGMENT  TRANSFORMATION 

(1! 

highlighting 

SEQIEtrr  HIGKLIOITING 

segment  priority 

SEGMENT  DISPLAY  PRIORITY 
SEGMENT  PICK  PRIORITY 

(2) 

detectability 

— 

NOTES 

1)  invisible  segments  arc  not  mapped. 

2)  The  elements  shall  appear  consecutively  m  the  metafile  but  may  appear  in  any  order. 
G.5.8  Mapping  of  metafile  function 
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(3KS  function 


CGM  eieisent 


WRITE  ITEM  TO  METATELE  APPLICATION  DATA  (1) 

I«}TES 

I)  Th«  GXS  item  type  is  mapped  to  the  CGM  ideniirier. 

G.6  Metafile  Interpretation 
G.6.1  Introduction 

This  sub-clause  describes  bow  metiTile  elements  fmm  a  version  2  meuTiIe  generated  by  a  GKS  program  Kcordtng  to 
the  mapptng  described  in  sub-clause  G  J.  are  subsequently  inierpreied  by  the  GKS  INTERPRET  ITEM  function 
and/or  the  MI/CGM  workstation.  Other  guidlines  for  interptetauon  are  poiible. 

Those  CGM  elements  which  do  not  map  to  a  GKS  item  are  viewed  as  directives  to  the  MI/CCM  workstation  itseif. 
so  that  it  may  correctly  reed  the  meuflie  contents. 

A  number  of  the  elements  below  are  specified  as  causing  GKS  tute  list  entries  to  be  set.  and  have  parameters 
spect/led  in  VDC  (which  corresponds  to  GKS  NDO-  The  GKS  state  list  entries  are  m  WC.  The  VDC  £NDC)  are 
mapped  by  the  inverse  of  the  current  normalizauon  iraruformaiion  before  the  GKS  state  list  values  are  set.  The  table 
also  includes  item  types  to  be  renaned  to  GKS.  These  are  adopted  from  GKS  Armea  E 


G.6.2  Mapping  of  delimiter  elements 

CC2t  Element  GXS  .'iecafile  Interface  Item  Notes 


BEGIN  METAFILE 

- 

- 

(1) 

END  METAFILE 

END  ITEM 

0 

(2) 

BEGIN  PICTURE 

- 

- 

(2) 

BEGIN  PICTURE  BODY 

CLEAR  WORKSTATION 

1 

(4) 

END  PICTURE 

- 

- 

BEGIN  SEC31ENT 

CREATE  SEGMENT 

81 

END  SEGMENT 

CLOSE  SEGMENT 

82 

NOTES 

1)  The  first  CGM  element  imerpreied  by  the  Ml  workstauon.  The  metafile  desaipoon  table  immediately 
follows.  Its  ciemenu  mform  the  MI  worksution  how  to  read  the  meufile. 

2)  No  ftothcr  items  may  be  read. 

3)  Appropriate  GKS  state  list  values  are  set  to  correspond  to  CGM  defaults.  Appropriate  workstation  state 
list  values  on  active  OUTPUT  and  OUTTN  workstaiioiu  are  set  to  correspond  to  CGM  defaults.  It  is  not  miendcd 
that  this  action,  or  the  imerpretation  of  any  picture  descriptor  elements,  cause  any  immediaie  dynamic  changes  to  the 
view  sutfacc.  which  ia  cleared  upon  BEGIN  PICTURE  BODY  -  the  unpiemeniaiion  may  wish  to  buffer  these 
actions  to  suppress  such  changes,  if  such  changes  ae  undesirable.  Only  picture  descriptor  elemenu  may  be 
interpreuKl  tautl  BEGIN  nCTURE  BODY 

4)  Caiaet  a  CLEAR  WORKSTATION  on  til  active  workstations. 


G.6~3  Mapping  of  metafile  descriptor  elements 

All  elements  ia  this  class  oontaia  only  diroctives  to  the  MI  workstation,  their  interpieution  does  not  correspond  to  the 
invocation  of  any  GXS  function. 


cot  Element 


GKS  Metafile  Interface 


:em 


Notes 


METAFILE  VERSION 
METAFILE  DESCRIPTION 
VDC  TYPE 
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(1) 


INTEGER  PRECISION 
REAL  PRECISICW 
INDEX  PRECISION 
COLOOR  PRECXSICW 
COLOOR  INDEX  PRECISION 
MAXIMUM  COLOOR  INDEX 

COLOOR  valoe  exte;  * 

METAFILE  ELEMENT  LIST 
METAFILE  DEFAULTS  REPLACEMENT 
FONT  LIST 
CHARACTER  SET  LIST 
CHARACTER  CODING  ANNOUNCER 
MAXIMUM  VDC  EXTENT 
MAXIMUM  NPC  EXTENT 
SEGMENT  PRIORITY  EXTENT 


(2) 


(3) 

(4) 
fS) 


NOTES: 

1)  The  viiue  of  the  panmeter  must  be  2. 

2)  Used  to  ncrmalize  colour  direct  values  to  the  continuous  range  of  real  numbers  (0.1  ]. 

3)  Used  to  normalize  VDC  range  (i.e.NDC)  and  applies  to  VDC  type  INTEGER  or  REAL 

4)  Used  to  normalize  NPC  range  to  allow  the  proper  position  of  the  .NPC  EXTENT  (worksuiion 
window)  within  the  normalized  NPC  range  (the  unit  square). 

5)  Used  to  normalize  segment  priority  to  the  continuous  range  of  real  numbers  [0.1 1. 

G.6.4  Mapping  of  picture  descriptor  elements 


cot  Eletnenc 


GKS  Metafile  Interface  Iten  Notes 


COLOUR  SEIZCTION  MODE 

- 

- 

background  colour 

- 

- 

DEVICE  VIEWPORT 

DEVICE  VIEWPORT 

WORKSTATION  VIEWPORT 

72- 

SPECIFICATION  MODE 

- 

- 

DEVICE  VIEWPORT  MAPPING 

- 

- 

LINE  REPRESENTATION 

POLYLINE  REPRESENTATION 

51 

MARKER  REPRESENTATION 

POLYMARKER  REPRESENTION 

52 

TEXT  REPRESENTATION 

TEXT  REPRESENTATION 

S3 

FILL  REPRESENTATION 

FILL  AREA  REPRESENTATION 

54 

PATTERN  TABLE 

PATTERN  REPRESENTATION 

56 

COLOUR  TABLE 

COLOUR  REPRESENTATION 

57 

NOTES: 

1)  The  VSU  specifier  may  be  either  MILUMETOES  WITH  SCALE  FACTOR  with  meinc  scale 
factor  equal  to  1000.0.  or  PHYSICAL  DEVICrE  UNITS.  DEVICE  VIEWPORT 
SPECIFICATION  MODE  may  occur  only  within  METAFILE  DEFAULTS  REPLACEMENT. 

2)  The  isotropy  flag  must  be  FORCED  and  the  alignment  flags  must  be  LEFT  and  BOTTOM. 
DEVICE  VIEWPORT  MAPPING  may  occur  only  within  METAFILE  DEFAULTS 
REPLACEMENT. 


G.6.5.  Mapping  of  control  elements 

CGM  Element  GKS  Metafile  Interface  Item  Notes 


201 


VDC  IWmSR  PRECISION 
VDC  REAL  PRECISION 

auxiliary  colour 

TRANSPARENCY 

CLIP  RECTANGLE  CLIPPING  RECTANGLE  61 

CLIP  OTtCATOR  CLIPPING  INDICATOR  62 

SAVE  PRIMITIVE  ATTRIBUTES  3  -  _  ’ ' 

RESTORE  PRIMITIVE  ATTRIBUTES  3  - 

CLIP  VOLUME 


G.6.6  Mapping  of  graphical  primitive  elements 

oat  Element  GKS  Metafile  Interface  Item  Notes 


POLYLINE 

DISJOINT  POLYLINE 
POLYMARKER 
APPEND  TEXT 
TEXT 
POLYGON 
CELL  ARRAY 
GOP 

NOTES 

1)  The  text  flag  should  be  Tina!'. 


G.6.7  Mapping  of  attribute  elements 

cot  Element  GBtS  Metafile  Interface  Item 


POLYLINE 

POLYMARKER 

TEXT 

FILL  AREA 
CELL  ARRAY 
GOP 


12 


13 


(1) 


1 


LINE  BUNDLE  INDEX 
LINE  TYPE 
LINE  WIDTH 
LINE  COLOUR 


POLYLINE  INDEX 
LINE  TYPE 

LINE  WIDTH  SCALE  FACTOR 
POLYLINE  COLOUR  INDEX 


21 

22 

23  (1) 

24  (2' 


MARKER  BUNDLE  INDEX 
MARKER  TYPE 
MARKER  SIZE 
MARKER  COLOUR 


POLYMARKER  INDEX 
MARKER  TYPE 
MARKER  SIZE  SCALE  FACT 
POLYMARKER  COL  INDEX 


25 

26 

27  (1) 

28  (2) 


TEXT  BUNDLE  INDEX 

TEXT  FONT  INDEX 

TEXT  PRECISION 

CHARACTER  QCPAMSION  rACTOR 

CBARICTER  SPACING 

TEXT  OSLOQR 

CHARACTER  HEZGaT 

CHARACTER  ORXENTATICM 

TEXT  PATH 

TEXT  ALIGNMENT 

CHARACTER  SET  INDEX 

ALTERNATE  CHARACTER  SET  INDEX 


TEXT  INDEX 

TtXT  FONT  AND  PRECISION 
TEXT  FONT  AND  PRECISION 
CHARACTER  EXPANSION  FACTOR 
CHARACTER  SPACING 
TEXT  COLOUR  INDEX 
CHARACTER  HEIGHT 
CHARACTER  UP  VCtT  OR 
TEXT  PATH 
TEXT  ALIGMtENT 
TEXT  FONT  AND  PRECISION 
TEXT  FONT  AND  PRECISION 


29 

30  (3) 

30  (3) 

31 

32 

33  (2) 

34  (4) 

34  (4) 

35 

36 

30  (3) 

30  (3) 


FILL  BUNDLE  INDEX 
INTERIOR  STYLE 
FILL  COLOUR 
HATCH  INDEX 
PATTERN  INDEX 
PATTERN  SIZE 


FILL  AREA  INDEX 
FILL  AREA  INTERIOR  STYLE 
FILL  AREA  COLOUR  INDEX 
FILL  AREA  STYLE  INDEX 
FILL  AREA  STYLE  INDEX 
PATTERN  SIZE 


37 

38 

40  (2) 

39 
39 

41 
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riLL  REFEwara:  point 


PATTERN  REFERENCE  POINT 


42 


ASPECT  SOURCE  FLAGS  ASPECT  SOURCE  FLAGS  43  (5) 

PICK  IDENTIFIER  PICK  IDENTIFIER  50 


NOTES: 

1 )  The  default  jpeciiication  modes  scaled'  applies. 

2)  The  default  colour  selection  mode  'indeaed'  applies. 

3)  Four  CGM  eietnents  supply  the  relevant  parameter  values  of  ihe  GKS  TEXT  FONT  AND 
PRECISION  item  (cither  explicitly  or  implicitly  by  default):  TEXT  FONT  INDEX,  TEXT 
PREQSION,  CHARACTER  SET  INDEX  and  ALTERNATE  CHARACTER  SET  INDEX. 
The  corresponding  GKS  font  number  may  be  determined  as  described  in  sub-clause  G.4.8.2.  The 
occurrence  of  only  one  of  the  four  CGM  elements  uniquely  indicates  the  mapping  to  GKS 
TEXT  FONT  AND  PRECISION.  The  occurrence  of  more  than  one  CGM  element  within  one 
sequence  in  any  order  causes  the  corresponding  GKS  item  to  be  muimcd  once. 

4)  Two  CGM  elements  supply  the  relevant  parameter  values  of  the  GKS  CHARACTER  VECTORS 
item  (either  explicitly  or  implicitly  by  ^fault)  :  CHARACTER  HEIGHT  and  CHARACTER 
ORIENTATION.  The  occurrence  of  only  one  of  the  two  COM  elements  uniquely  indicates 
the  mapping  to  GKS  CHARACTER  VECTORS.  The  occurrence  of  the  two  CGM  elements 
within  one  sequence  in  any  order  causes  the  corresponding  GKS  item  to  be  returned  once. 

5)  TEXT  FONT  ASF  and  TEXT  PRECISION  ASF  must  be  equal:  they  correspond  to  GKS 
TEXT  FONT  AND  PRECISION  ASF.  HATCH  and  PATTERN  INDEX  ASF  must  be  equal; 
they  correspond  to  GKS  FILL  ARF  ^  <TYLE  INDEX  ASF. 


G.6.S  Mapping  of  escape  and  external  elements 

03i  Element  GKS  Metafile  Interface  Item  Notes 


ESCAPE  ESCAPE  6 

MESSAGE  MESSAGE  5  (1) 

APPI^ICATION  DATA  USER  ITEM  >100 

NOTES 

1)  The  action  required'  flag  should  be  no.action’. 


G.6.9  Mapping  of  segment  control  elements 


CGM  Element  GKS  Metafile  Interface  Item  Notes 


COPY  SEOCNT 

INHERITANCE  FILTER 

•• 

G.6.10  Mapping  of  segment 

attribute  elements 

C01  Element 

GKS  Metafile  Interface 

Item  Notes 

SEGMENT  TRANSFORMATION 

SET  SEGMENT  TRANSFORMATION 

91 

SEQ4ENT  HIGHLIGHTING 

SET  HIGHLIGHTING 

93 

SEGMENT  DISPLAY  PRIORITY 

SET  SEGMENT  PRIORITY 

94 

(1) 

SEGMENT  PICK  PRIORITY 

SET  SEGMENT  PRIORITY 

94 

(1) 
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NOrrES: 

1)  Both  CGM  SEGMENT  DISPLAY  PRIORITY  and  SEGMENT  PICK  PRIORITY  supply  ihc 
paiatneter  value  of  the  GKS  SET  SEGMENT  PRIORITY  item. 
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CGM  Addendum  1 


Part  2 
Draft  Copy 
August  1989 
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Pa^tlO 


Kid  the  fallowing  to  the  end  of  sub-clause  3  J: 

3y8  for  Segment  Conool  Elemena  and  Segment  Ai!hbt.ie  Bemenis 
3/13  for  Rasuv  Elemena 

Pagtll 

Add  the  following  to  table  1; 


opcode  Thu  coding  8  bit  coding 


BEGIN  SEGMENT  opcode 

210 

2/2 

03/0 

02/5 

END  SEGMENT  opcode 

2/0 

2/6 

03/0 

02/6 

NAME  PREaSION  opcode 

3/1 

3/0 

03/1 

03/0 

MAXIMUM  VDC  EXTENT  opcode 

3/1 

3A 

03/1 

03/1 

SEGMENT  PRIORTTY  EXTENT  opcode 

3/1 

3/2 

03/1 

03/2 

DEVICE  VIEWPORT  opcode 

3/2 

2/7 

03/2 

02/7 

DEVICE  VTORT  SPEC.  MODE  opcode 

3/2 

2/8 

03/2 

02/8 

DEVICE  VIEWPORT  MAPPING  opcode 

3/2 

2/9 

02a 

02/9 

LINE  REPRESENTA'nON  opcode 

3/2 

2/10 

03/2 

02/10 

MARKER  REPRESENTA'nON  opcode 

3/2 

2/11 

03/2 

02/11 

TEXT  REPRESENTATION  opcode 

3/2 

2/12 

03/2 

02/12 

FILL  REPRESENTA'nON  opcode 

3/2 

2/13 

03/2 

02A2 

EDGE  REPRESENTATION  opcode 

3/2 

2/14 

03/2 

02/14 

LINE  CUPPINO  MODE 

3/3 

2/6 

03/3 

02/6 

MARKER  CLIPPING  MODE 

3/3 

2/7 

03/3 

02/7 

EDGE  CUPPING  MODE 

2/2 

2/8 

03/3 

02/8 

BEGIN  RGURE  opcode 

3/3 

2/9 

03/3 

02i9 

END  FIGURE  opcode 

3/3 

2/10 

03/3 

02/10 

NEW  REGION  opcode 

3/3 

2/n 

02/2 

02/11 

SAVE  PRIMITIVE  CONTEXT  opcode 

3/3 

2/12 

02/2 

02/12 

RESTORE  PRIMmVE  CONTEXT  op. 

3/3 

2/13 

03/3 

02/13 

ORCrULAR  ARC  CENTRE  REVD  op. 

3/4 

2/8 

03/4 

oz 

CONNECTING  EDGE  opcode 

3« 

2/9 

03/4 

02/9 

PICK  IDENTIFIER  opcode 

3/6 

2a 

03/6 

03/2 

COPY  SEGMENT  opcode 

3/8 

2/0 

03/8 

02A) 

INHERH'ANCE  FILTER  opcode 

3/8 

2J\ 

03/8 

02/1 

CUP  INHERn'ANCE  opcode 

3/8 

2a 

03/8 

02/2 

SEGMENT  TRANSFORMATION  opcode 

3/8 

2f2 

03/8 

028 

SEGMENT  HIGHUGHTTNG  opcode 

3/8 

2K 

W.//8 

02/4 

•  SEGMENT  DISPLAY  PRIORITY  opcode 

3/8 

20 

03/8 

02/5 

SEGMENT  PICK  PRIORITY  opcode 

3/8 

20 

(8/8 

02/6 

Pate27 

Add  the  following  tub«iauaa  after  tub-clauic  6.12: 

<.13  Viewport  Point  pamracters 

A  viewport  Point  (VP)  ia  a  pair  of  VC  icalan  (Viewpen  Coordinate)  repretenting  the  a  and  y  eoordinaies  of  a  point  in 
viewport  specification  space.  A  VC  scalar  is  either  an  integer  or  real  number  according  to  whether  VIEWPORT 
SPECIFICATION  MODE  is  'ftaction  of  display  surface',  'millimeircs  with  scale  factor'  or  ‘physical  device  uniu'. 

When  VIEWPORT  SPECIFICATION  MODE  is  ‘fraction  of  display  turface‘.  the  encoding  of  the  viewport  point  data 
type  it  aa  described  in  6.4  Coding  Real  Numbers.  The  size  of  the  viewport  pomt  parameters  is  limned  by  'he  current 
REAL'PRECISION  value. 
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Whm  VIEWPORT  SPOFICATTON  MODE  a  miOxaMM  •»«!»  K«k  tmam' m  p*iy»*«a  d«»«oi  «»»*  «*•  *»sasw|  ef 
(he  vicwpan  pots  <iatt  ryjM  ta  ai  dnoibad  m  6J  Cadtttg  InM|«n.  ’Dm  ct  tim  pom  pmmmmn  u  iimiwd 

by  tiw  cumn  IKTECER  PRECISION  ^tim. 

S.14  Naat  parantters 

Nam«  pvamcian  m  oodtd  u  iotaten  (Bute  formal)  ai  NAME  PRECISION. 

Pe^eJI 

Tha  foiiowwi  form  nib-clauMs  I  1 .6  and  1. 1 .7 

l.l-«  BEGIN  SEGMENT 

<BECIN  SECMEVT-opc»<l«;  3/0  VS> 
oiamc  ictmenMdanuriar> 

1.1.7  END  SEGME.NT 
<£ND-5£CMENT opcode  3J0  2/6y 

Poft  H 

Add  Lhe  fotlowQii  10  vha  eamanvaiad:  clamant  aco  of  mfr-clauaa  I.Z.  1 1 : 

i<sni«|*r2>  IVERJ  static  SET) 

lEXTENDEDPRIMnTVES  SET! 

!<tfiia|er4>  !  VER.2  STATIC  GKSM  SET) 

Page  36 

The  foilowtni  form  lub-clautea  S.2.16  to  S.Z.18 

S.2.16  NAME  PREaSION 

<NAME  PREaSlONopeoda:  3fl  3Kt> 

<»iu|er  larfcA  nama-fioda  *  l> 

NCTTE:  The  iarieat-nanaoodi  indiaaa  how  many  biu  occur  in  the  Urftoi  poiatble  mapondc  for  a  name. 

•.2.17  MAXIMUM  VDC  CXTE>fT 

<MAXIMUM  VDC  EXTENT-opooda:  3/1  3/l> 
apotncfim  comcr> 
epotfit^acond  ornnao 

1.2. IS  SEGMENT  PRIORITY  EXTENT 

eSECMETfr  PRIORITY  EXTENT  op-oodr  3/1  3/2> 

<suagar  ftaniwum-aa|Biam-pnoriiy-Tahia» 
omatcrfflaauRum-safmau-(aMhiy'vaiiia» 

PagtJS 

The  foilowtiii  form  cvb<lanMB  IJ.S  to  8 J.lS 

8.3.8  DEVICE  VIEWPORT 

<DEVlCE-VIEWPORT-«pooda:  3/2  2/7> 

.  <vp:  nrii  cotTiar>  ) 

<vp  ;  tocond  coincr>  ) 

8.3.P  DEVICE  VIEWPORT  SPEanCATlON  MODE 
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<0EVIC1  VIEWTORT  SPECinCATION  MODE  ofnc^  3/2  Z«> 
<mRMnHd;VC  «f«ctriar> 

<a«ai;  mctne  Kak  fae>sr> 

•CMUimfaMd;  VC  ffMofico  >  <nuf  «~0> 

I  <su«t«r::> 

I  <8u«(fr2> 


t  fraoicn  of  rariaot ) 

{ssn  wNh  auk  faaoti 
(ptrynui  dcvaoc  unitai 


•J.IO  DEVICE  VIEWPORT  MARRING 


<0EV1CE  VIEWPORT  MARRING  o|v«Kk:  3/2 1V> 
ununicratid:  iaomft)r-(Uf> 

<tni*«nmi«d;  tiaru)ORut-«ii(pin«n(  ria4> 

<antfncntMt  vmui  aiip«n<ni-fU|> 


<cmuncnied;  uoat>py-n4(> 
Ktrumemtd:  horzonui  tiifn/nent  na{> 

<afurnsu«d:verucai-  aiifrvncnt 


<mtntr0> 

(nDcfoRadt 

tbOMt! 

<»mef*r0> 

r«i 

<»nteger.  1> 

(oarotl 

<]ntct(r:2> 

|n*ki 

<«ni*|tr<)> 

(bociom  j 

lOBBt) 

<intc|er:L> 

(t^l 

IJ.ll  LINE  REPRESENTATION 


<UNE  REPRESENTATION-opcodt:  3/2  ZflQ> 
Kotciex:  lin«-lMndl«-indcL> 

OBdcx:  UM-rypt> 

<Golow  -(pannco 


<]n(iu.  Une-bwuSc-indeu 
ondcx:  lint-iypo 


<po»iu»t  mtcgcra 
<im*|tr.  l> 
onupr  2> 
<ajiu|pr  3> 
<:m(c|cr  4> 
<uu«|cr  S> 
oni«|«r 


(nbdl 

(<kk{ 

(dtt) 

(MhImI 
(dHh  401-^01) 
Igmaw  lint  type) 


<line-wid(h-tpecirier>  • 

I 

<C8kiur-fpecina>  ■ 

I 

<iia«gtr  eo)ow-ind«i9  ■ 


o«aL  line  wtdih-tcak-faaao 
I  if  LINE  WIDTH  SPEaFlCATTON  MODE  u  luW  1 
<VDC;  liM 

(if  LINE  WIDTH  SREOFIC  MODE  IS  tlnotuie  I 
<imet*r.  eoioor  mda> 

(if  COLOUR  SElECnC^  MODE  U  MnedI 
‘<RGB> 

(if  CXILOUR  SELECnCW  MODE  IS  <fina| 

naegeo 


tJ.!2  marker  RCPRCSENTATTON 


<MARIC£R-R£PR£SENTATI0N4pR>de:  3/2  2/n> 
<indn:  nuKte-kiidk<ind*i> 

<wdt*:  mmk»r-4ypt» 

^nuka-taB-tpadr ^ct> 

<CBiow-ipaein«> 


<mdex:  nuriccrbundk-kndex> 

■  <potiavc  ime|CT> 

<mdBx:  m«fccr-(ype> 

m  <inugcr  1> 

(dot) 

<  <»u«|er.  2> 

(pkBl 

1  <nuefer  3> 

(MHRlk) 

1  integer  4> 

(ekek) 

1  <iiiuger.  5> 

(aw*) 
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I 


<»••*«'.  (fmtiKmatar  ryptt 


<>»ta’-ii»-ipaeiC«r>  , 

I 

<aUoiM-tpmarm>  , 


t 


ovHCfcr  cdaur-tndlu> 

•J.U  TEXT  REPRESEXTATION 

<  1  La  I  -REPRESENTATION'Opood*:  3/2  2/1 

<aid«s:  uai-buneBc-ndio 
onufcr  iKii-roM-ind«x> 

<«unMrai«fc  i«ct-piacition> 

‘Qui:  dunaar-fpmn|;> 
ouL  espmnan-f«;tar> 

<eakMc- •paeifi4r> 

mt-faundb-avteo  , 

<atta|cr  t«ii-lQtu-tnct«x>  , 

<«iu)n«nMd:  iKit-(ncijian>  . 

t 

I 

<ruL  expauvon-ricttio  , 

IJ.U  nu.  REPRESENTATION 

<PILL-REPRESEOTATIONK>peodc:  3/2  2/1 3> 
<md»x:  (IQ-few)clU-nikx> 

«cm»n(ntad:  inwior-ttyio 
^colour  spaQlitr> 

<indB:  hadi-iakx> 
cindn:  p«i«R-in(ks> 


<indH(;nn-butidk-indax>  . 

<«Riiineaiatl:  iawior  stylo  a 

I 

I 

t 

I 

I 

«eokKir  spndfico  . 

I 

<»d«s;  hatd>-ind«x>  . 

I 

I 

I 

I 

I 

I 

cindu;  p«isn-indR>  . 

8.3. IS  ,  EDGE  REPRESENTATION 


cmi:  nwtMT  sm-toic-faeaiio 

{if  MARKER  SIZE  SPEC  MCK3E  »*  ictled  i 

<VOC.  mmhm  m*> 

(if  marker-size  spec  MOC  •  IS  •bsotuK ! 
‘Onm$tr  aoiom  a»^tst> 

{ if  COLCX/R  SELfXTTON  MODE  IS  mck  isd ! 

(if  COLOUR  SELEC  MCOE  u  <taaa  j 
^non-flaf  M*«  a«c|cr> 


<petiuv«  mw|(T> 
<potiu*«  aut|cr> 
<a)t(ttrO> 
<3ni«|crl> 
<mi«|cr2> 
^ton-nc|auv(  r<iX> 


(wv>*i 


Icturaoa) 


<patiiiv«  imef«r> 

<imt|«rO>  (hc'low 

<iRie(erI> 

<ime|er2> 

<imc|crj> 

<aUB|cr.4> 

<iBiC|«r7icf»civo 


(soiid 
Ipwm 
(hKti 
(onpty 
Iprrv He  style ) 


<iBHf«.uiimr  tndn> 

(if  COLOUR  SELECTION  MODE  is  mdeted) 
<RCB> 

(if  COU3UR  SELECTION  MODE  is  dma  I 


<teettrj> 

<Bieg«rd> 

^mcgcmcgHivo 

<potiiive  inietcr> 


(heniBnUI) 
(*wail 
(poMtive  slope  I 
(aetHivc  tlo^l 
(>wra/»Hiit«i  qoss) 
(pOBtivsA*f  cnssst 
(prrvHc  styles  I 


<EDGEREPRESENTAT10N-«pcod*:  3/2  2/14> 
<ind«;  ed|e-bundle-tndex> 
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<indn:  tdiv-typo 

<»lour-«pacxG(r> 

<iMl  -  i^-iMniaaMndBi» 
'Ondux:  ad|c>ty|M> 


wtdlh-fpKifco 


<fioi<HV-fpaciricr> 


<wt<ger  coloW'indcx> 


(Hisi) 

{<Mj 
14x1 

idMit-dM-da) 
{pnvaitKtfctypc' 

•  ont  ■^»tdtt>.«c»k-f>aor> 

ttf  EDGE  wnmi  SPED  MODE  u  »cxS<*3  i 
I  <VDC  «%•  •niat> 

(tf  EDGE  WIDTH  SPEC  MODE  u  ibnjlu.* 

•  <mttw;  cal(Mr-«dM> 

(if  COLOUR  SELXCnON  MODE  a  uvfc.oe 
I  <RCB> 

(if  COLOUR  SELamON  MOTiE  u  dirrc. 

■  «nn-ncg«t)vt  aut|cr> 


*■  <lx>no««  ■U(|a> 

■  <nutcr  1> 

I  oaugasr  3> 

I  <Siu|«r  3> 

I  <»!«•■:  4> 

I  <iai«(ar  3> 


Pagt^O 


The  foliowing  form  Tub-cUu*at  8.4.7  to  8.4  iS 
8.4.7  LINE  CUPPHS'C  MODE 


■<LINE  CUPPINC  MODE-opc0de>'  3/3  2/6> 
egmmrmwt  elippent  moeko 

^emunenud:  clipping  mado 

8.4.8  .Marker  clipping  mode 


«iniegerO> 
<8tugtr  t> 
<8»cgcrZ> 


<LINE  CUPPING  M0DE.opcod4»:  3/3  2/7> 

<4rasncn(ad:  clipping  modx> 

<BiuiTienu«t  clipping  modt>  .  <m«gerO> 

I  <mi(tgcrl> 
I  «inugcr2> 

8.4.9  EDGE  CUPPING  MODE 


<L1NE  CUPPING  MODE-opeodo:  3/3  2/l> 

<wuiiwi—dL  clippiBg  n>o<k> 

<«uiiimttd:  ctippinf  niad4>  •  <aiieycrO> 

I  <intt8«il> 


8.4.10  BEGIN  ncURC 

<dBEClN  nCURE^rpeedt  3/3  2/9> 

8.4.11  END  nCURE 

<£ND  FIGURE.opoode:  3/3  2/10> 


(boat 

(ihk*i 

(toaa  (hen  ihtpci 


[boul 

Idwpel 

(locut  then  ihepc  I 


(bcuil 

(looK  ilMB  ihape) 


2H 


JU.«  Ntw  tSGION 


<NEW MEGION-<itnod«:  3/3  2ni> 

«.4.0  SAVE  PIUMrnVE  CONTEXT 

^lAVE  PEO^i i  Ai  i  kIBtji  3/3  2/1^ 

«uiar  oantao 

E4.14  EESTORE  PRIMITIVE  CONTEXT 

<RESTOREPRlMrnVEATTIUBtJTES-opeod«;  3/3  2/)3> 
<3UiMe  caiuuo 


P 0^*45 


Tha  feOowing  form  lub-clauM  t  J.20  and  8.3  2) 

1.3.20  CIRCULAR  ARC  CENTRE  REVERSED 

<CIRCUIwKR  ARC  CEI^E  REVERSED-opcxxk:  3/4  IX> 
<poiRC  oostpomo 
<VDC:  DX,.*ttrt> 

<VDC  DY^iaro 
<*/DC  DX.«t> 

<VIXI  DY.«d> 

<VDC  radiuo 

1. 5.21  CONNECTINC  EDGE 


<CONNECnNC  EOCE^jpewk:  3/4  2/?> 


Page  54 

TIm  faiiowwi  fomu  srib-cUuac  8.6J6 
EEJ5  nCK  IDENTinER 

<PiaC-ID<opeode:  3/6  3/Z> 

<ara«:  pick-idcn&ll«r> 

PattS6 


Tba  foOowinf  foma  ).9 

s.9.1  COPY  SEGMEPrr 

4COTY-SBGMENT-opoodt:  3/12/Qfr 


maffanuaga  •ppiication> 


<anncnad3C|in0it 

snraibnmtian  tpplica(Km> 


'Owl;  111  > 
«nl:  il2> 
<rwil:  t2I  > 
<ra4  «22> 
<vde :  al3  > 
<*<le  :  »23> 


<wi«t«r-0> 


(nol 
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1 

<ntc|atl> 

ty»l 

t.9.2  mHEWTANCE  FILTE* 

<^NHimA^KX-^LTEll•<>ww^  3/»  Zn> 

filat>Ml«cson-lao-» 

<maamwmk  it'menan  mamf;^ 

otmaMOMd:  Q}ttr-Ml«aMi-lisc>  ■ 

«diu«|arO> 

{line  bundk  Mki ) 

1 

(tincryivl 

1 

t 

jlimooiour) 

1 

<mc|a-4> 

{ liM  dippmt  mole ! 

1 

<8UCt«'J> 

(fnarkcrtMi^  tnttni 

1 

<B»cftr4> 

(nvahia’rypEl 

1 

<xme|fr7> 

(martotucl 

( 

( marker  cDiourj 

I 

<5«u*|«r9> 

I  marker  clippm|  moee : 

1 

<m*tcr.lO> 

lutai  bundia  andea  i 

/ 

iicaifoni  tnctcal 

i 

<m«e|erl2> 

(MUtpracaaoni 

1 

<int>|firl3> 

(GharaaB- rrpaniaon  facet  i 

( 

<intc(erU> 

|dianc«rif9aan(t 

i 

<iRi«|«rl5> 

|iaatcoicMr( 

1 

(danoBheihtl 

1 

<mt*Hrl7> 

{charaocr  anrmauor;  j 

1 

<ini*lfr  ll> 

luatpaih) 

1 

<a»unfrl9> 

(U«ait|!rm«nt| 

1 

<aMn«^21> 

I  no  bundle  tndei ! 

t 

<srrt«»tr.Il> 

imanoi 

1 

«intttcr2i> 

Ifaioobur) 

1 

<8»c(cr25> 

(hMdinkal 

<antegcr2&> 

(paaoTt  indcil 

I 

•emtgfwr27> 

(ad|c  bimdU  mdci  1 

1 

^nu%tr2>> 

(adHerypel 

1 

<3«t*«r29> 

(adtewaMt) 

1 

<Btat«rJ0> 

(adfacDiour) 

1 

<nicffr31> 

iad|t  vnibiUty) 

1 

<imtfcr32> 

jadfa  dippeif  mode  1 

f 

<im«ftr33> 

(fiS  re&nmoa  pom  1 

1 

«inueftr34> 

jpasamtiicl 

f 

<imet«r35> 

{MaiUarycokMrl 

1 

«ime|tr36> 

1 

<BiM««r.3t> 

jiinaaanbimt) 

1 

<jm«|cr39> 

jmarkar  Mn^wel 

1 

iwnm'AKaaal 

I 

(dnracar  aar9MMa! 

1 

((ai«a«aHaa| 

1 

<ini|«;43> 

{adgaaB^Maa} 

( 

'dBttf«;44> 

IpaaMm  timlMeal 

1 

'«1nutii.a 

(enpai  oonrall 

1 

<Wt|M  J 

{pick  idMifiar) 

1 

<inM|tr45> 

(aB  aBitaMM  and  conaol  ] 

1 

<inuifar> 

(ill 

1 

(Imtypa  ASF| 

1 

<wu^r» 

IttMwkUiASF) 

( 

«inu|ar> 

(Imooieiir  ASF) 

{tnaricar  typa  ASF) 

1 

CUW|{(I"^ 

(mntar  lisa  ASF) 

i 

<inufir:> 

( marker  odour  ASF) 

1 

<inuger> 

1  leal  fern  indea  ASF) 

1 

<iauger> 

[teat  PREOSION  aSF) 

1 

«irut*r> 

(charaeiar  eaptmston  facior 
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* 

i 

<  <iBMtcr> 

(diaracMr  qpaoRt  A 

1  <»Mfcr> 

{•nt  ooigia' ASF! 

i  oni«gar> 

{inariat  iiyi*  ASF) 

>  *iuLtptr> 

jfiB  oi^MT  ASF) 

1  <iBU{ar> 

nckx  ASF) 

*  <inu«tr:> 

ipiawi  EKbai  ASF) 

1  <iau|«r:> 

(«l|Cty|»ASF) 

{■dtt  «<iRh  ASF) 

1  <ncg*r> 

j«dC(  natoar  ASF) 

(limASBl 

■  <iM«f(r47> 

(m«tar  ASFtj 

>  <aucg«r«t> 

{(cztASFt) 

1  <iuagcr4Y> 

ichMoar  ASF*) 

1  <mu(cr3(t> 

tltUASBl 

(alfc  ASF*) 

'  ont«tcr52> 

{ilIASF*| 

<enumert(cd:  Klccuon  Mtii;ig> 

■  <im«|er:0> 

(tuu.Iiii) 

CLIP  INHERITANCE 

<CLIP  INHERITANCE<»pK)d«;  3/1  2/2> 
<attancm«(l:  cti(v.inhcnuneo 

‘  <wie|erl> 

fKgnSTSii 

<cttuncn<ad:  Hnutg> 

i»ui«,!uo 

SEGMENT  TRANSFORMATION 

1  <inutcr'. !  > 

(inienacuon) 

<SECMENT-TRANSFORMA'nON-opctjde;  3/«  2n> 

<]umc:  sctpnm-Kknufico 
<trm/oimuion  miinx> 

<trinifornuuon  m»m*>  .  owj  ill> 

<rwi:  *12  > 
<r«»l:  (21  > 
<nai:  i22> 
■evdc :  *13  > 
<vdc  :  »23  > 

*.9.S  SEGMENT  HIGHLIGHTING 

<SECMENT-HICHUGKnNG-opco<le:  3/1 2/<t> 

cum*:  M|RMm>ideRuriar> 
ctnumcmad:  M|iMm-hi(hIi|hiin|> 

<BamcstgiTMm  id«ittn«> 

MgiMni-hiihliihivii? 

•.9.*  SEGMENT  DISPLAY  PRIORITY 

<SeCMEKr.plUORrTY.a|KPdr  3y*  VS> 

<Bamc  MfBMn<idmilMr> 

«ni«|«r;  MpMni.(iispUy-phonty> 

««pn«m.4»»pI»y.pnorny> 

*  9.7  SEGMENT  PICK  PRIORITY 


2/<t> 


■  <>aitg«r> 

•  oiMgtr  0> 
I  «iaui(tr  l> 


■qjonii**  inie|er> 


(mmidl 

|hi|hlifh««d) 


<SECMENT.PiaC-PRIORm'^«je:  3/1  V6> 
oanir  M|mcnM<knuf1er> 
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CBUcgcr.  ;)ick-pnani>'> 
cinugtr  pidc  priori  ty> 


<potiuvc  inue|cr> 


Faft56 

Add  the  followmi  to  the  end  of  cUiac  9 

NAME  PRECISION  JO 

Pag* 60 

Add  the  followtni  to  the  end  of  Annex  A 

<name  precuion  vxluo  <inic{er>  (tee  g^) 

oiewpon  pomo  ■:»  <inieg«rxmtc|er> 

I  <icjixTexi> 

<nmo  3ii  <jtnu|er> 

<2x2  miiru  of  rexU>  r»  {i«eg  9) 

<2x  1  maim  of  vdcs>  ode  vaiue><2)  (Mtg.9) 
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FageJS 


Add  the  following  to  table  I: 

N 

SI  at  integer 

94 

NR  (.2*»(np.t) 

precision  (np) 

(-tjp/8) 

to 

2**(np-lVli 

vp 

(RR) 

or 

BVSP(-2*BR) 

VSPR-IRR) 

Page  19 

(U) 

BVSP  (•2«BI) 

VSPR-(IR) 

Add  the  following  to  Table  Z 

8  Segment  Control  uid  Segment  Aitnbtue  elemenu 
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Add  the  folio  wing  to  uble  3: 

BEGIN  SEGMENT  6  N  BN  NR 

END  SEGMENT  7  b/«  o  n/t 

Code  Descrtpuon 

6  BEGIN  SEGMENT:  tut  1  panmeter 
Pi:  (segment name)  segment  tdcndiler 

7  END  SEGMENT:  has  no  panmeters 
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Add  the  following  to  table  4: 


NAME  PRECISION 

16 

N 

maximum  VDC  EXTENT 

17 

2P 

SEC  PRIORITY  EXTENT 

18 

21 

Code  OescTipuon 

16  Name  precision:  haa  t  parameter 

Pi :  (iiveger)  name  praeiaian:  8.16^  or  32 


BN 

8.16.202 

16 

2BP 

VDCR 

VDC  EXTENT 

ZBI 

R 

0.  235 

the  only  valid  values 


17  maximum  VDC  EXTENT:  haa  2  panmeten: 

Pi :  (poim)  (im  point 
PZ  (^im)  aaoond  poim 


18  SEGMENT  PRIORITY  EXTENT:  haa  2  praieten: 


Pi :  (integer)  miniinum  sagmem  priority  value 
P2:  (integer)  maximum  segment  priority  value 


I 
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PattU 


Add  to  the  no«P2  of  METAFILE  ELEMENT  UST; 

vorJl-ttKic  (-12) 

•ondad-pritnitivci  (-IJ) 

wJ'gksm-tutic  (-1.4) 

J*ag*24 

Add  to  the  end  of  the  note  P2  for  SCALING  MODE 

Note  that  this  pvimctcr  is  always  encoded  u  Floating  Point,  regardless  of  the  value  of  the  fue<ynoaiing  Hag  of  REAL 
PREOSION. 

Pagt24 

Add  the  following  to  table  3; 


DEVICE  VIEWPORT 

g 

2VP 

2BVP 

VPR 

see  below 

DEVICE  VIEWPORT 

9 

ER 

BEi-BR 

lO.U) 

0.. 

SPECIFICATION  MODE 

DEVICE  VIEWPORT 

MAPPING 

10 

3E 

3BE 

(0.11 

1 

(0.U1 

0 

(0.U) 

0 

LINE  REPRESENTATION 

11 

2IX. 

2BIXv 

vDCEDCR. 

nfa 

(VDCor 

(B  VDCor 

wvVDCR  or 

R).CO 

BRVBCO 

■W.RR.COR 

MARKER  REPnON 

12 

2IX. 

2BIX-V 

•*DCR.D(E 

nfa 

(VDCor 

(B  VDCor 

♦♦VDCRor 

R).CO 

BPHBCO 

♦vRR.COR 

TEXT  representation 

13 

2D(. 

2BDCv 

♦DCR. 

n/a 

E 

BEv- 

(0.1.2). 

2R.CO 

2BRvBCO 

RR.COR 

nu.  representation 

14 

DC. 

BDCv- 

♦OCR. 

nfa 

ECD. 

BEvBCO^ 

{0_4).CX3E 

2DC 

2BIX 

DCR.i«R 

EDGE  representation 

IS 

2DC. 

2BTX* 

♦DCILOCR. 

(VDCor 

(B  VDCor 

♦♦VOCR  or 

R).CO 

BRHBCO 

♦♦RR.COR 

Code  Deacripuon 

g  DEVICE  VIEWPORT:  has  2  pnmctcn: 

Pi:  (vp)  (irtt  point 
P2:  (vp)  second  point 

The  default  DEVICE  VIEWPORT  is  the  antin  device  view  siafaee  if  the  latter  is  rectangular,  or  the  largest 
rectanguier  subset  having  iha  de«rud  aspect  raba  if  the  view  surface  is  not  rectangular.  The  default  is  set  so 
that  the  (fast  pent'  is  balm  tod  to  the  M  of  the  'second  point’  at  seen  by  dit  viewer. 

9  DEVICE  VIEWPORT  SPECIFICATION  MODE  hat  2  praietcts: 

PI:  (tnumaratad)  viewport  tpadficatienuniu:  valid  values  are: 

0  ItaiaianefdRaringta  <00 

1  nulUmemt  with  teak  star 

2  physical  device  tsiiu 

P2:  (real)  metric  scale  factor,  ignored  if  PIwO  or  P1a2 

'  Note  that  this  perameter  is  always  encoded  as  Floating  Point,  regardless  of  the  value  of  the  ruced/floating  flag 
of  REALPREaSION. 
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VIEWPORT  MAPPING:  Has  3  pffvnciAn: 

PI:  (cnumented)  iaooopy  dm;  valid  values  are: 

0  nxfotced 

1  fawBd 

P2;  (eBumeratad)  horiaar'aJ  alignment  flag:  v»lid  v»iues  are- 
0  left 

1  cmc 

2  right 

P3:  (enumerated)  verocal  alignment  dag:  valid  values  are: 

0  bottom 

1  earn 

2  Bjp 

LINE  REPRESENTATION:  has  d  parameters: 

PI:  (indes)  line  bundle  index 

P2:  (index)  line  type:  the  following  values  are  Jtandaidaed: 

1  solid 

2  didi 

3  da 

d  dash-dot 

5  daih-dot-dot 

negative  for  private  use 

P3:  (vdc  or  real)  absolute  line  width  or  line  width  scale  factor 

Pd:  (eolow)  line  colour  its  form  depends  on  COLOUR  SELECTION  MODE. 

Marker  representation:  has  d  parameters: 

PI :  (index)  marker  bundle  index 

P2;  (index)  mariter  type  the  following  values  are  lundardixad: 

1  da 

2  phu 

3  aaensk 

d  CBde 

3  aoM 

negative  for  privtic  use 

P3:  (vdc  or  real)  absolute  marker  width  or  marker  size  scale  factor 

Pd;  (eoioiff)  marker  colour  its  form  depends  on  COLOUR  SELECTION  MODE. 

TEXT  REPRESENTATION:  has  6  perimeters: 

Pi;  (index)  text  btmdle  index 

P2:  (index)  text  font  index 

P3:  (enumemed)  text  precision:  valid  values  ve 

0  sang 

1  dmw 

2  saoke 

Pd:  (ml)  chneser  spacing 
PS:  (ml)  cherecter  cxpnsiuM  factor 

P6:  (colour)  text  ooloar;  its  fona  dependa  on  COLOUR  SELECTION  MODE 

FILL  REFRESENTATTON:  hai  5  pvametss: 

PI:  findn)  GIl  «a  bundle  index 

P2:  (enuDNmed)  interior  style:  valid  values  are: 

0  hollow 

1  sidid 

2  pattern 

3  hsich 

d  onpty 

R;  (colour)  fiD  colour  itt  form  deptnds  on  COLOUR  SELECTION  MODE 
Pd:  (index)  hatch  index:  the  following  values  ire  standardized: 

1  hotuontal 


■L  ««ra«i 

3  pane'**  tiofM 

4 

5  oambmM  md  Horuonui  tUa 

6  aamtamd  kft  ma  nttu  ii4vu 
atficria  f«  pmaa  um 

PS;  (iadn}  p«B«ni  ndn 


13  EDGE  representation  Nm  4  itaraiMurv: 

PI ;  (sidcx)  vift  bwidlt  mda 

P2.  (inelax)  adt*  <yiM:  dM  foOowjii  »tkMi  am  (uniatjuadL 
!  M>iid 

2  4mh 

3  dot 

4  dwIVdDt 

5  duh-d«<iM 
n«|uiy«  for  pnvua  um 

n.  (vdc  or  ttai)  alMoiuta  <4tt  width  or  Itw  width  Kak  fictor 

P4  (cciour)  «d|t  colour  iit  form  drpvndr  on  COLOUR  SELECTION  MODE 


Pate  26 


Add  (h«  faiiow«i(  !o  table  6: 


LINE  CUPPING  MODE 

7 

£ 

BE 

0 

MARKER  CUPPING  MODE 

1 

£ 

m. 

jO,;.;; 

0 

EDGE  CUPPING  MODE 

9 

E 

BE 

1 0.  ’  D I 

0 

BEGIN  nCURE 

10 

iVa 

0 

V* 

END  FIGURE 

11 

tva 

0 

MW  RJECION 

12 

tVt 

0 

fVi 

Vt 

SAVE  PRJMmVE  CONTEXT 

13 

N 

BN 

VR 

fV't 

RESTORE  PRIMmVE  CONTEXT 

14 

N 

BN 

NR 

7 


9 


10 

11 

12 

13 


UNE  CUPPING  MODE:  h«  1  pwncter 

Pi:  (wamaraiadl  ciipfmi  moda:  v*hd  v«hMa  arc 
0  lam 

1  Rm*)* 

2  loetB  than  ihapt 


Marker  cupping  mode;  hu  1  parammr. 

Pi :  (cntimaraMM)  dippinc  rnedc  valid  vahiaa  «rc 
0  lom 

1  itapa 

2  bm  than  ihopa 

EDGE  CUPPING  MODE:  ha  1  paranamr 
Pt:  (emoMnaad)  moda:  vaEd  vahaM  arr 


0 

1 

2 


BEGIN  FIGintE:  hmmpmmmm, 
END  FIGURE  haa  no  panmim 
NEW  REQON;  has  no  paramatan 


SAVE  PRJMITTVE  OONTEXT:  has  I  parttnatar 


Pi:  (natna)  eontaat  name 
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14 


«£STOIl£  inUMTnVECOfnrEXT:  ba*  1  p«w»i*ttr 


1^1:  (Mm)  eams  nam 

Fat€2t 


MA  iIh  foDowosg  n  ubk  7; 


ORCWAR  ARC  CENTRE 
REVERSED 

20 

P.4VDC 

BP*4BVDC^ 

VDCR.VDCR.  Ai 

CONNECTINC  EDGE 

21 

VDC 

oA 

BVOC 

0 

»*VDCR 

Na  nrt 

Code  DcioipdoB 

20  aRCUlAR  ARC  CSmE  reversed  h«  6  parMtinm 
Pi ;  (point)  com  of  cveJ« 

PI  («dc)  d*lu  X  for  itan  voaor 
P3;  (»dc)  dciu  Y  for  nan  voeior 
P4;  (vde)  dalu  X  for  end  vaetor 
PS:  (vde)  datea  Y  for  end  vaeior 
P6:  (vdc)  raebua  of  nrcla 

21  COffNECTTNG  EDGE  has  no  parsneten 
PagrJJ 

Add  lilt  foUowtni  to  udia  8; 

PICK  IDENTIFIER  36  N  BN  NR  0 

Code  OetcTTpoon 

36  PICK  IDENTIFIER:  haa  1  parameter 
PI:  (name)  pick  idmufiar 

Pat*  39 

The  fotiowint  fanni  nitM:lauae  7. 10 

7.10  Segment  Control  and  Segment  Attribute  Elements 
Table  1 1  •  Eneadini  of  teement  eoncrol  aid  sagmam  atstbute  ckmenu 


Etenam 

El 

Pinm 

Parvneiar 

Parameter 

Default 

ami 

Id 

Type 

Liat 

Langih 

Range 

COPY  SEGMENT 

I 

N.4R, 

BNtdBR-^ 

NRJIR. 

-.0 

2VDC 

ZBVOC* 

VDCR, 

E 

K 

lai) 

mHERTTANCE  FILTER 

2 

ttEJE 

Oh-DBE 

io-43nau 

-.1 

CUP  INHERITANCE  3 

E 

BE 

(01)  0 

SEGMENT  TRANSFORM 

4 

N.4R, 

BN-mBRi- 

NR.RR. 

ii/a.1. 0.0.0. 

2VDC 

2BVDC 

VDCR 

1.0 

SEGMENT  HIGHUGNnNG 

5 

N.E 

BNi^E 

NR.  (0.1) 

nfa.0 

SEC  DISPLAY  PRIORITY 

6 

NJ 

BN<-BI 

NRJR 

iVa.aae  below 

SEGMENT  PICK  PRIORITY 

7 

N.I 

BN-»BI 

NRJR 

iVa.aae  below 

Coda  Oaacripuon 

1  COPY  SEGMENT:  hu  8  ^rameutra: 
Pi:  (naine)saimcm  idcnuTier 
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TTic  next  6  pnmcicn  «e  componcna  of  «  3l2  matrix  of  the  fan... 


IP2P3  P6J 
fP4  P5  P71 
wflBPC 

PZ:  (rcxi)  X  component 
P3:  (reel)  x  rauuon  component 
P4:  (rcaJ)  y  reuuon  component 
P3;  (reel)  y  waie  oomponcm 
P&  (vde)  X  crimlation  component 
F7:  (y<le)  y  inraiauan  component 

P8;  (enumented)  tegmem  cranafarmation  appiicatton:  valid  valuct  are: 

0:  IB 

1;  yai 

IKHERITANCE  FILTER;  hu  i<vo  parameucTt.  "nie  fim  it  a  lift  of  up  u>  •••••••••••  jimpgie  or  group 

dcsignaion.  The  tecond  it  a  itnglc  tetung  value. 

Fl:  (enummated  liu)  li«  of  one  more  of: 

0  line  bundle  index 

1  line  type 

2  line  w«dth 

3  line  colour 

lint  clipping  mode 

4  mBfcer  bundle  aidex 

3  ouitotype 

6  moriceraze 

7  mvfcer  colour 
maric<r  clippuig  mode 

5  text  bwtdle  index 

9  text  font  index 

10  textprccuion 

11  dunem  ezpenxion  factor 

12  character  tpacmg 

13  text  colour 

14  character  height 

13  eharacur  onentatian 

16  text  path 

17  text  alignment 

30  nn  btaidlc  index 

21  iaieriar  style 

22  GU  colour 

23  haichindex 

24  paoemindex 

23  edge  bwidle  index 

35  odgeiype 

27  uigiwiith 

a  adgeaokae 

79  edge  viathility 

edge  dipping  mode 

30  fin  raferenoe  poim 

31  IBoamnsi 

S  aaailivy  colour 

34  finaaantmtet 

36  taataontmtes 

37  chaneur  aiBibaies 

31  fiHauribinea 

39  edge  ao'Rwtaf 

40  paoetn  aoributei 

42  oinpin  control 
pack  identifier 

43  all  aahbutes  and  control 
all 
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liattypc  «f 

iin*  wid:h  af 

lim  colour  ui’ 

nurkortypeuf 

luirter  luc  ml 

maker  Qolow  uf 

iKufom  index  isf 

text  preosiofi  mf 

dunew  expansion  fanor  uf 

duncser  ipecsi|  xsl 

text  colour  uf 

inicnor  uyie  ul 

fin  colour  uf 

huch  index  uf 

puum  index  uf 

ad|e  type  uf 

•d(e  width  uf 

ed|«  colour  uf 

line  ufs 

merker  ufs 

text  ufs 

fin  ufs 

edfctsfs 

xUufs 


n.  (enumemed)  setting;  vtlid  viiues  an; 

0  sutejist 

1  segment 

CUP  INHERTTANCE;  hu  1  pxnmeier 
Pi:  (enumcrxted)  clip  mhentxnce:  valid  values  are; 
0  sutejist 

1  segment 


SEGMENT  TRANSFORMATION;  hu  2  pwneterx: 

Pi:  (name)  segment  idenuTier 

The  second  parameter  consisu  of  a  3x2  matrix  of  the  form: 

P2:  (2x2  matrix  of  reals.  2x  I  matrix  of  vdcs) 

SEGMBTT  HICHUGHTINC:  hu  2  parameters; 

Pi:  (name)  aegmem  idcminer 

P2:  (ammeruad)  highlighting;  valid  valuea  arc: 

0  BHnal 

1  highKghieri 

SEGMENT  DISPLAY  PRIORITY;  hu  2  paramcscn; 

Pi:  (nane)  mptmm.  idanrifier 

P2:  (iaugar)  legmani  di^tiay  priority 

The  defuilt  of  the  tegmam  ^lay  priority  is  equal  to  the 

atnunra  itgmem  prieniy  vaiua  (see  tttb<iaasc  7  J) 

SEGMENT  PICK  PRIORITY:  hu  2  perameten; 

Pi:  (name)  wgment  idcntiner 

P2:  (inttgcr)  tegmcm  pick  prioriiy 

The  defauU  of  the  segment  pick  priority  is  equel  to  the 

minitnum  scgmat  prioniy  value  (see  sub-clause  7  J) 


Faf*40 


M&  tfaa  foQovmi  to  th«  end  of  cUuic  8: 

NAME  PRECISION  16 

Fat*  ^'2 

Add  the  foUawtDg  lo  che  list  of  refsanoet; 
eviewpart  porno  =■  <Bnet€r(2)»e«Jf7> 

0«ie»  ^  <intc|er> 

<2x2  KUtrvt  of  reaii>  =■  <ieKl><4) 

<2x  1  maim  of  vdci>  =>  <vdc  viiuofl) 

Fag**S 

Add  the  followut|  to  the  lui  of  elemcmu: 

CUu  Elemeni  Element  Name 
Cait 

0  6  BEGIN  SEGMENT 

0  7  END  SEGMENT 

I  16  NAME  PRECSION 

1  17  MAXIMUM  VDC  EXTENT 

\  18  SEGMENT  PRIORITY  EXTENT 

2  8  DEVICE  VIEWPORT 

2  9  DEVICE  VIEWPORT  specification  MODE 

2  10  DEVICE  VIEWPORT  mapping 

2  n  UNI  REPRESENTATION 

2  a  MARKER  REPRESENTATION 

2  D  TEXT  REPRESENTATION 

2  14  FIU.  REPRESENTATION 

2  IS  EDGE  REPRESENTATION 

3  7  UNE  CUPPING  MODE 

3  8  MARKER  CUPPING  MODE 

3  9  EDGE  CUPPING  MODE 

3  »  BEGIN  FIGURE 

3  11  END  FIGURE 

3  a  newreqon 

3  13  SAVE  PRIMTITVE  CONTEXT 

3  M  RESTORE  PRIMmVE  CONTEXT 

4  3D  CIRCULAR  ARC  CENTRE  REVERSED 

4  21  CONNECTING  EDGE 

3  38  PICKDENTIFIER 

8  1  COPYSBCMENT 

I  2  INHERITANCE  FILTER 

8  3  CUP  INHERITANCE 

8  4  secmenttransformation 

8  S  SEGMENT  nCHUCHTING 

8  6  SEGMENT  DISPLAY  PRIORITY 

8  7  SEGMENT  PICK  PRIORITY 
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CGM  Addendum  i 


Part  4 
Draft  Copy 
August  1989 
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Poftil 


Add  the  foDovuig  to  the  end  of  mb-clauc  S  J  J 


N 

VC 


<1>  (inme) 

<R>t<I>  {vMwponcDondiniasdMfttkpcndinc 

on  DEVICE  VIEWTORT  SPEanCATION  MODEl 


VPOINTREC 


<VCxSEPxVC> 


VP  n*  <VPOINTREC>t<  <LEFT  PAREN><OPTSEJ>><VPO[hnTlEC><OFnEP> 

<iUCHT  PAREK>  > 

(COORDINATE  in  viewport  ipeariceooii  rpKe.  Ps.-  ^theMs  dc  optxTnal.  If  they  ax  uMd.  they  thai!  {roup 
exactly  two  real  or  ouegcr  nuntben.  dcpmdini  on  ueVICE  VIEWPORT  SPECIFICATION  MODE  The 
perauhesued  form  u  mcreled  to  aid  readability  of  the  mcufUc  1 


ROWMATRIX  «R;nRST  ELEMENT  IN  ROW> 

<SEP> 

<R;SECOND  ELEMENT  IN  ROW> 
<SEP> 

<VDC;LAST  ELEMENT  IN  ROW»  i 
«LEFT  PAREN> 

<OPTSEP> 

<R;FIRST  ELEMENT  IN  ROW> 
<SEP> 

<R;SECOND  ELEMENT  IN  ROW> 
<SEP> 

<Vtx:.LAST  ELEMENT  IN  ROW> 
<OPTSEP> 

<RICHT  PAllEN» 


TM  <JlOWMATRIX> 

<SEP> 

■eROWMATRDCr 

(2x3  nnsfomution  maou  in  row-nujor  order.  Pwenthcaa  am  opuonai.  If  they  v«  uiad. 
they  shall  group  exactly  two  reid  mimbm  and  one  VDC  manber.  Tlie  paramhanzad  form  is  imended  to  aid  rcadahiliry  of 
the  mcufDe.  if  there  are  not  three  nnmbars  in  each  pamtthaaiaad  poop,  the  meufilt  is  non-coaforming  iniarchangc. 
Any  anampiad  error  recovery  or  exception  handling  which  a  metafile  intirptetm  may  use  in  this  siimuon  is  nciiher 
HafiTwd  nor  consffxined  by  ISO  8d32M.  A  matafile  imerpretar  nee  not  uas  the  pvtntheies  in  paning:  in  this  case,  they 
as  ntied  as  SPACE  charaocri  rather  than  et  NULL  chsrecten  (i  A.  they  act  ss  soft  del  imiicrsjL  I 


PttflZ 

Add  the  following  to  the  end  of  Mh-ciaBta  S.43 


ALL 

can 

EXTENDED 

FIGURE 

FILTER 

FORCED 

FRACTION 

GKSM 

WTERSECnON 

UXUS 

MATRIX 

NAME 

NEW 

ncx  • 

PRlMmVES 

REGION 
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SAVE 

SHAPE 

STATIC 

THEN 

UNITS 

VERa 


^af€l2 


Add  (he  foilowmg  to  the  end  of  tub-cl«usc  S-4  4 


ATTRIBLrrEfS) 

CUPPING 

CONNECTING 

CONTEXT 

DEVICE 

IXSPLAY 

WGHUGHTINC 

IDENTIFIER 

INHERITANCE 

MAPPING 

MIUJMETER 

PHYSICAL 

PIXEL 

PRIMITIVE 

PRIORITY 

REPRESENTATION 

RESTORE 

REVERSED 

SEGMENT 

transformation 

VIEWPORT 


Faftl4 


Add  the  following  to  the  end  of  mb-dauic  S.4  J 

BEGIN  SECMSrr 
END  SEGMENT 
NAME  PRECISION 
MAXIMUM  VDC  EXTENT 
SEGMENT  PRIORITY  EXTENT 
DEVICE  VIEWPORT 

DEVICE  VIEWPORT  SPEOFICATrON  MODE 

DEVICE  VIEWPORT  MAPPING 

UNE  REPRESENTATION 

MARKER  REPRESENTATION 

TEXT  REPRESENTATION 

pnx  REPRESENTATION 

EDGE  REPRESENTATK^I 

UNE  diPPlNO  MODE 

MARKER  CUPPlNa  MODE 

EDGE  CLIPPING  MODE 

BEGIN  RGURE 

END  FIGURE 

NEWRECnON 

SAVE  PRIMmVE  CONTEXT 
RESTORE  PRlMinVE  CONTEXT 
ORCUlAR  ARC  CENTRE  REVERSED 
CC^fNECTlNOEDGE 
PICK  IDENTIFIER 
COPY  SEGMENT 
INHERITANCE  FILTER 
CUP  INHERITANCE 


attr 

CUP 

CONN 

CONT 

DEV 

DISP 

WCHUCHT 

D 

INH 

MAP 

MM 

PHY 

PEL 

PRLM 

PRI 

REP 

RES 

REV 

SEC 

TRAN 

VP 


BECSEC 

ENDSEG 

NAMEPREC 

MAXVDCEXT 

SBCPRIEXT 

DEWP 

DEWPMODE 

DEVVPMAP 

UNEREP 

MARKERREP 

TEXIREP 

FILLREP 

EDCEREP 

UNBCUPMODE 

MARKERCUPMODE 

EDGGCUPMODE 

BfiCFIGURE 

ENDFICURE 

NEWRECION 

SAVEPRXMCONT 

RESPRIMCONT 

ARCCTRREV 

CONNEDCE 

PKXID 

COPYSEC 

INHFILTER 

CUPINH 
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SEGMENT  niANSFORMATlON  SECTKaNS 

SEGMENT  VBIBILnT  SECVIS 

SEGMENT  HICHUGKnNC  SECHiCHl. 

SEGMENT  DBPU^Y  PRIORITY  SECDISPPRI 

SEGMENT  PICX  PRIOIUTY  SECPICXPRI 


PoflS 


KU  (h(  foilowinf  to  ihc  end  of  sub-clause  6^ 

BEGIN  SEGMENT  ^  BECSEC 

<SOFTSEP> 

<N;SEGID> 

<TERM> 

END  SEGMENT  ENDSEG  <TERM> 


Pott  17 


Add  lo  (he  sid  of  METAFILE  ELEMENT  LIST. 


The  wCTds  VER2STATIC.  EX  I  ENDED  PRIMITIVES  and  VER2CKSMSTATIC  mty  ilio  be  used  in  ihu  itr. 
Poftl? 


Add  iha  folldwini  lo  (he  end  of  sub-clausa  6  J 


NAME  PREOSION  =•  NAMEPREC 

«SOFTSEP> 

<tMlNINT> 

«SEP> 

<LMAXINT» 

^rERM> 

MAX  VDC  EXTENT  =■  MAXVDCEXT 

<SOFTSEP> 

<P;FIRSTCORNER> 

<SEP> 

<P;SECONDCORNER> 

^TERM> 

SEChfENT  PRIORITY  EXTENT  =«  SECPRIIXT 

«SOFrSEP> 

<LMINSECPR1> 

<SEP> 

cLMAXSECPRb 

•dTERMb 


PofeJS 


Add  ite  foUow«g  10  (ha  ead  of  iab<iaiaa  6  A 


DEVICE  VIEWPORT  =■  OTWP 

<SOFnEP> 

<VP:FmSTCORNER> 

<SEP> 

<VP;5ECt»IOCORNER> 

<TERM> 


DEVICE  VIEWPORT  SPEOnCATION 
MCHJE  n*  DEWP 
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<SOFnEP> 

<FllACnONlMMiPHYDEVUNTTS> 

<SEP> 

<ltSCALEfACTOR> 

^rERM> 

DEVICE  VIEWPORT  MAPPING  :r.  DEVTCEVPMAP 

<50FTSEP> 

<NOTK)RCEDlFORCED> 

<SEP> 

<l.EFncrRiRICHT> 

<SEI>> 

<BOTTOMlCTRrrOP> 

«TERM> 

UNE  REPRESENTATION  UNEREP 

<SOFT5EP> 

<I;BtJNTX.EIND0C>  (pruavel 
<SEP> 

•<LUNFnrpE> 

(Ii«oiid.  2«li(h 

3«doc  Andath-dot 

WMh-dM-doi 

^  iurplentcnution  dependent  | 

<SEP> 

<V:LINEWI0TH>  (non-neeiuvel 
<SEP> 

<K;UNECOLR> 

<TERM> 

marker  REPRESENTATION  MARKERREP 

<SOFTSEP> 

<LBUNDLE1ND0C>  (poeiDvel 
<SEP> 

<I*(ARKERTYPE> 

"V  MWTiik.  <»circle 
5*obb(*) 

_  ^  impluHeni’n  dependent  | 

<SEP> 

<V:MARIC£RS1Z£>  fnon-necitive) 
<SEP> 

<K;MARKERC0LR> 

■«TERM> 

TEXT  REPRESENTATION  =■  TEXTREP 

«SOFREP> 

<tBUN0li4BWDEX>  {patiir.'t| 

<5EP> 

<tPONTl?fDEX>  (pomivel 
<SEP> 

<ST1UNGICHAR1STR0KE> 

<SEP> 

<R:5PACING> 

<SEP> 

<R:FACTOR> 

<SEI>> 

<IC;TEXTCOLR> 

<raiM> 

FEU.  REPRESENTATION  3»  FIUREP 

<SOFTSEP> 

<LBUNDLQNDEX>  (poiiovel 
<SEP> 
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<H<XIjOWlSOlJD<PATtHATCH!EMPn'> 

<SEP> 

•eJCFIUrOLto 

<SEP> 

<LHATCHINT)EX> 

( 1  ■tanzoruU -neniui 
Sa^onuvc  slope 
towtgshvt  slope 
SailMtiz/vtn  crew 
6**/'  slope  crew 
<0  intpIcmcnL  depestdent 

<SEP> 

<l;PA'nNDEX>  {positive I 
^IIM> 

EDGE  REPRESENTATION  c-  EDGEREP 

<SOFTSEP> 

<1:BUNDLE1NDEX>  fposiuvel 
<SEP> 

<l;EDGErYPEs> 

({■wild.  2»dish 
Stlot.  rt»lsilHtot 
Mssh-doc-dai 

<0  implencnution  dependent ) 

<SEP> 

<V:EDCEWIDTH>  (non-neg*tive| 

<SEP> 

<K:EDGECOLR> 

<TERM> 


Page  19 

Add  dve  following  to  the  end  of  sutxliuse  6  J 


LINE  CUPPING  MODE  =■  UNECUPMODE 

<SOFrSEP> 

^ijOCUSlSHAPElLOCUSTHENSHAPEs' 

-<iTERM> 

MARKER  CUPPING  MODE  MARKERCUPMODE 

<j;OFTSEP> 

<UXUSISHAPBLOajSTHENSHAPE> 

<TERM> 

EDGE  CUPPING  MODE  =-  EDGBCUPMODE 

<SOFTSEP> 

<LOCUSSHAPEIIjOCUSTNENSHAPE> 
<TERM> 

BECnCUR£4frERM> 

ENDFICURE<rTERM> 

:re  NEWREQON<TERM> 

.  IMPUEDCEVIS 
<SOFrSEP> 

<OFRON» 

<TERM> 

SAVE  PRIMmVE  CONTEXT  SAVEPRIMCOKT 

<SOFTSEP> 


BEGIN  RGURE 
ENDHCURE 
NEW  REGION 
IMPUCTT  EDGE  VISIBIUTY 
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<N<X>NTOCrNAMEa. 

<TERM> 

RESTORE  PWMmVECXJNTEXT  RESPRIMCOW 

<sorrsEP> 

<N<X)NTEXTNAM 

^TERM> 


Page  24 

Add  <he  followint  to  the  end  of  nitxlauac  6.6 

ORCULAR  ARC  CENTRE  REV  ARCCTRREV 

<CTRARCSPEC> 

<TERM> 

CONNECTING  EDGE  =»  CONNEDG  <TERM> 


Page  28 


Add  die  following  to  the  end  of  sui>-cliuM  6.7 


PICK  IDENTIFIER 


=■  PICKID 

<SOFTSEP> 

<N;PICXID> 

<TERM> 


Page  29 


The  followini  fonm  sub-cliuse  6.10 


6.10  Encoding  segment  control  and  segment  attribute  elements 

COPY  SEGMENT  .•:»  COPYSEG 

<SOFTSEP> 

<N;SEC;iD> 

<SEP> 

•dTM:TRANSMATRIX> 

<NOIYES> 

<TERM> 

••••••••PROPER  ENCODINGS  TO  BE  ADDED  ONCE  UST  AGREED 

INHERITANCE  FILTER  =-  INHFILTER 

<cSOFrSEI>> 

<L1NEINDEXI 

UNETYPEI 

UNEWIDin 

UNECOUti 

UNECUFMCnXI 

MARKERINDEXI 

MARKERTYPEI 

MARXERSIZEI 

MARKEROnJll 

MARKEROJPMODEI 

lEXTINDEXl 

TEXTTONTINDEXI 

TEXTPREa 

CHARACTEREXPANI 

CHARACTERSPACEI 

TEXTCOLRI 
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line  type  uf 
lincwidihuf 


CHARHQCHr 

CHAROWI 

TEXTPATHI 

TEJfTAUCW 

FILLjVDEX} 

INTSTYLEJ 

FIUjCOLRI 

HATCHINMXl 

PATINDEX] 

EDGEINDEX] 

EDGETYPEl 

EDCEWtDTH 

EOCECOUU 

EDGEVTSl 

EDGECUPMOOe 

FILLREFERENCEPn 

PATSrZE! 

AUXCOLRl 

TRANSPARENCY! 

UNEATTRI 

MARKERATTRI 

TEXTATTR) 

CHARATTRI 

RLIATTRI 

EDCEATTRI 

PATATTRI 

OITTPUTCONTROU 

PICKIDI 

ALLATTRI  concrol' 

ALL! 


line  cQlour  uf 
mariur  type  uf 
nurior  SOB  uf 
mvfcs  colow  uf 
tuxfouinkx  uf 
tcnprnxion  uf 
dunc&u  espmsion  factor  uf 
duneter  spacini  asf 
UDueokraruf 


interior  nyi«  uf 
ODcoiowuf 


haidiinkxuf 
patem  index  aaf 
ed|aiypea*f 
edfi  width  uf 
adgeoolowuf 

UNEASFSI 

MARKERASFSI 

TEXTASFS 

CHARASFSI 

nLLASFSI 

EDCEASFSi 

ALLASFS> 

<SEP> 

<STATHJrnSECMENT.. 

<TERM> 


CUP  INHERITANCE  <CUPINH 

<SOFTSEP> 

<STATE_USTTIN7ERSECnON> 

<TERM> 
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SEGMENTTRANSFORM  ATION 


SEGTRANS 
<SOFTSEP> 

<N:SEaD> 

<SEP> 

<TM:TRANSMATRD(> 
<TERM> 

SEGMENT  HIGHLIGHTING  ;r»  SECHIGHL 

<SOFrSEP> 

<N:SECnO> 

<SEP> 

<NORMAUHIGHUCHTED> 

<TERM> 

SEGMENT  DISPLAY  PRIORITY  SECDISPPRl 

<SOFTSEP> 

<N:SECID> 

<SEP> 

<I;DISPLAYPRIORrTY> 

<TERM> 

SEGMENT  PICK  PRIORITY  SEGPICKPRl 

<SOFTSEP> 

<N:SEr.ID> 

<SEP> 

<I:PICKPRIORITY> 

<TERM> 


Page  30 


Add  the  foUowini  to  die  end  of  eUuie  7; 
Rck  idenufier 


NAME  PRECSION: 

MININT  0 

MAXINT  32767 
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